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 E6C42383C99 for ; Mon, 20 Apr 2026 07:58:27 +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=1776671909; cv=none; b=unVDg4g/R80heR6hhV4ieceKMAy352R28swS891pYdt2dynw2t42Xchiqp/5zBo8xpP/Wq2403flUYHfg+wvjZimsXsNw+wF24yYKV3/ICvn5dgoJ29s+40CUfXaCQI5kNnBX2eGlFIBSKUvoxVVD8kmgiWblq9rJpm2iXMw3j4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776671909; c=relaxed/simple; bh=X5G5mHY5kq5f3IvFP9CJtL2o3Q9QcWxvNB9CKbkfxyc=; h=MIME-Version:Content-Type:Subject:From:To:Cc:In-Reply-To: References:Date:Message-Id; b=QaiIWSopIScxRcCkKgzwmFyfkDtsdBDwrztwfPPk7P6yDgRY5WyWxOzeFaqfaznGgu1V1CPPAEJy3jbE5EL2zOdHVcOf5gkdCPnMz/W7j5EGo7bDy6nKJOXQT0+pXXZKYDw1j9wawKGXAfTlPVCCTsOs0zWayZmo3ALFvORq/Vw= 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=aclRDNpQ; 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="aclRDNpQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776671907; 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=+eOGQZSG/sTjuYk//asYw4DDdal69kUFJwf3nSU/tY4=; b=aclRDNpQmiA1L1vD+LZMC/wOP8gOyHr3lQHzZUbXSwh3SkotBCvJg/TIWScn8fbBEouCwd Yxl5Sh/+7Cx+/KxMEK3zdfeLYD52Fpv77zTyYiZ1YIsGmSfBpG21D2+0vUHWNRPa8vKbJe quHWpn6OV/XbtprQABJw+0ggOy4p0ho= Received: from mx-prod-mc-03.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-587-UMddlqhUOjKp5ngNkvFJwg-1; Mon, 20 Apr 2026 03:58:23 -0400 X-MC-Unique: UMddlqhUOjKp5ngNkvFJwg-1 X-Mimecast-MFC-AGG-ID: UMddlqhUOjKp5ngNkvFJwg_1776671901 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CCFCC195605E; Mon, 20 Apr 2026 07:58:19 +0000 (UTC) Received: from jlelli-thinkpadt14gen4.remote.csb (headnet01.pony-001.prod.iad2.dc.redhat.com [10.2.32.101]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 067AE195608E; Mon, 20 Apr 2026 07:58:13 +0000 (UTC) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH 1/2] cgroup/cpuset: record DL BW alloc CPU for attach rollback From: Juri Lelli To: Waiman Long Cc: 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 , cgroups@vger.kernel.org, sched-ext@lists.linux.dev, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: References: <20260417033742.40793-1-zhangguopeng@kylinos.cn> <20260417033742.40793-2-zhangguopeng@kylinos.cn> <6aca2465-1ea7-417a-beb8-e385fa3902bf@kylinos.cn> Date: Mon, 20 Apr 2026 09:58:11 +0200 Message-Id: <177667189136.43781.14481765787952757348.b4-reply@b4> X-Developer-Signature: v=1; a=ed25519-sha256; t=1776671893; l=1803; i=juri.lelli@redhat.com; s=20250626; h=from:subject:message-id; bh=X5G5mHY5kq5f3IvFP9CJtL2o3Q9QcWxvNB9CKbkfxyc=; b=6pUttxV2K5elVOMXaIeZE/fHVnx/DQzeySz6fQ2Z23/WKZo+WL9QdM2KGXIXIo7Lx7XiOSmdY 7uVb7Ve3NZJDQB9zQZhSj+wAwxJeazNvnT7MkxgSXqyAizLBbYVEq5i X-Developer-Key: i=juri.lelli@redhat.com; a=ed25519; pk=kSwf88oiY/PYrNMRL/tjuBPiSGzc+U3bD13Zag6wO5Q= X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 Hi! On 2026-04-19 22:31:29-04:00, Waiman Long wrote: > On 4/19/26 10:21 PM, Guopeng Zhang wrote: > > > 在 2026/4/18 2:51, Waiman Long 写道: > > ... > > Hi Waiman, > > > > Thank you for the review and for the Reviewed-by. > > 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. > > 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. But, if they don't and try to create DEADLINE task on cpusets that are subsets of a root-domain, that should fail, as the affinity mask won't be covering the entire root domain. So no BW allocated (and no additional data structures) for subsets either. Thanks, Juri