From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC2C48BE9 for ; Mon, 20 Apr 2026 02:31:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776652305; cv=none; b=Qhkgt9CdC+UtfEVWinBSA9Yt1w0CwZZyu5sFWGFOecu1lOsH8lmhSwdKC5tDcSgZjkfd5g+LpaWMRV57LOAupMn1PXq41xD0/YBHGSd5BxZDd97UiH8bOWxIIbfqqpM1ldd8Gqc3Rlmcwk4EdlreLuy02PZIK/NQhGe9dXRPbfU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776652305; c=relaxed/simple; bh=DoyTcXiVhC4VzaYJoR1An3TVuYGcevQxqFWrh/u+CR4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ZCKMTIYpICLeSvc+9b4UrcsnwzHkIfM7pxnWBfJvhFjSsS08o7md8az4NpQZfrevJSgyLJw/9u705AYDxdTwL/yODwvNVU5NtS+IC/R+P4zRH5iKN0G+n5HskHBPiHCteAgoA9Jhif9mnb1g8udlQuB9qHvuDNrByymbTyFTVRQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Xm7DA8iS; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Xm7DA8iS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776652303; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/kqlOzpHd/914Eoinh5TNTEwvLrAk8vIipzwkCQFsoo=; b=Xm7DA8iSAQJcl9Lc1aWPDaafWG51roiLv8uvL9ZR2/aXK9FltlcBfBV5/SFvjiYte+fzRM lVSUtvyygMAvVuzkv3hmm0v+9r2p4KNRHA6W+v89YzOcFc/zNnmROW2/UDoNTJsOTiFgNR n+lFeicd5hvk+BbYnGEFMGFXZUXXEPY= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-483-N5bVM-GLO02DMoiUT5V9ZQ-1; Sun, 19 Apr 2026 22:31:37 -0400 X-MC-Unique: N5bVM-GLO02DMoiUT5V9ZQ-1 X-Mimecast-MFC-AGG-ID: N5bVM-GLO02DMoiUT5V9ZQ_1776652295 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 60D461956080; Mon, 20 Apr 2026 02:31:34 +0000 (UTC) Received: from [10.22.80.68] (unknown [10.22.80.68]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 081FA3000C20; Mon, 20 Apr 2026 02:31:30 +0000 (UTC) Message-ID: Date: Sun, 19 Apr 2026 22:31:29 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] cgroup/cpuset: record DL BW alloc CPU for attach rollback To: Guopeng Zhang , tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com, void@manifault.com, arighi@nvidia.com, changwoo@igalia.com, shuah@kernel.org, chenridong@huaweicloud.com, Juri Lelli , Valentin Schneider , Dietmar Eggemann Cc: cgroups@vger.kernel.org, sched-ext@lists.linux.dev, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260417033742.40793-1-zhangguopeng@kylinos.cn> <20260417033742.40793-2-zhangguopeng@kylinos.cn> <6aca2465-1ea7-417a-beb8-e385fa3902bf@kylinos.cn> Content-Language: en-US From: Waiman Long In-Reply-To: <6aca2465-1ea7-417a-beb8-e385fa3902bf@kylinos.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 On 4/19/26 10:21 PM, Guopeng Zhang wrote: > > 在 2026/4/18 2:51, Waiman Long 写道: >> On 4/16/26 11:37 PM, Guopeng Zhang wrote: >>> cpuset_can_attach() allocates DL bandwidth only when migrating >>> deadline tasks to a disjoint CPU mask, but cpuset_cancel_attach() >>> rolls back based only on nr_migrate_dl_tasks. This makes the DL >>> bandwidth alloc/free paths asymmetric: rollback can call dl_bw_free() >>> even when no dl_bw_alloc() was done. >>> >>> Rollback also needs to undo the reservation against the same CPU/root >>> domain that was charged. Record the CPU used by dl_bw_alloc() and use >>> that state in cpuset_cancel_attach(). If no allocation happened, >>> dl_bw_cpu stays at -1 and rollback skips dl_bw_free(). If allocation >>> did happen, bandwidth is returned to the same CPU/root domain. >>> >>> Successful attach paths are unchanged. This only fixes failed attach >>> rollback accounting. >>> >>> Fixes: 2ef269ef1ac0 ("cgroup/cpuset: Free DL BW in case can_attach() fails") >>> Signed-off-by: Guopeng Zhang > ... >> The patch looks correct to me. >> >> Reviewed-by: Waiman Long > Hi Waiman, > > Thank you for the review and for the Reviewed-by. >> However, I have a DL bandwidth accounting question unrelated to this patch that I would like the scheduler people to clarify. The allocation of additional DL BW is based on the condition >> >>         if (!cpumask_intersects(oldcs->effective_cpus, cs->effective_cpus)) { >> >> IOW, additional DL BW will need to be allocated when the old and new cpuset doesn't overlap. However, they could still be in the same root domain. Does that mean we will be double counting it? > I think you are right to call this out. Looking at the > current logic, !cpumask_intersects(oldcs->effective_cpus, cs->effective_cpus) > does not obviously guarantee that the migration is crossing into a different > root domain. If the old and new cpusets are disjoint but still belong to the > same root domain, it does look possible that we reserve bandwidth on the > destination side without a corresponding subtraction from the source side. > I will try to reproduce that configuration and follow up with results. >> Looking from the other side, the root domain may have enough DL BW for the task migration, but the subset of CPUs in the cpuset itself may not have enough total DL BW to host all the DL tasks to be migrated, is that a problem? > my current understanding is that the DL bandwidth > accounting is done at root-domain granularity, not at arbitrary cpuset-subset > granularity. That is my understanding too. > That also seems consistent with > Documentation/scheduler/sched-deadline.rst, which says that deadline tasks > cannot have a CPU affinity mask smaller than the root domain they are created > on, and that a restricted CPU set should be achieved by creating a restricted > root domain with cpuset. A root domain should be created by creating cpuset root partition for v2 or using the cpuset.cpu_exclusive flag in v1. What is listed in the documentation is the ideal case, but users may not strictly follow the rule. Cheers, Longman > > So if a cpuset is only a subset inside a larger root domain, it does not seem > to get an independent DL bandwidth limit of its own. If that understanding is > correct, then the smaller cpuset not having enough bandwidth by itself would > be a limitation of that model rather than something this code checks > separately. I'd appreciate confirmation from the scheduler folks on that > point. > > Thanks, > Guopeng >> Cheers, >> Longman