From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CE69A3B3895 for ; Thu, 28 May 2026 09:47:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779961636; cv=none; b=ra9/qyKop7DgjSqstrI/zG6FwLHnwFqkFha17sDdOPdTac+rYGx55/mBG/PqyNJjagcHYOZueFq1VyGnig6rvALV11OJpL8MENhD7BoBCZVCvxIhz4UJfjAXnQYxiflosmU6bQApulBwHZBpSkHkPE3w9l1DA2XjZzspiuEVJUI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779961636; c=relaxed/simple; bh=YlKU4csTXK8ywpOcrpn79cOrMBbEX1Im3VbMgIZOtSU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mR7k6vcUNcD/O8xlzvyPp2uNHBZJ7TKo7ILFbO/o4nNnx/qdgnp52Pidf5RN0Xh1aMFaNlkctllUidKMgXL0eExGAoJLFGD3x8T9Zrlv9wWcUT9YXYEBYLrkKvZRlnMv0xfWy1ifF7I92o0XGlrf6PXEdIwrbx/Mk4g6SR7stb0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=T2oyc0pW; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="T2oyc0pW" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4760C4402; Thu, 28 May 2026 02:47:09 -0700 (PDT) Received: from [10.1.29.59] (e127648.arm.com [10.1.29.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7EFCC3F632; Thu, 28 May 2026 02:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1779961634; bh=YlKU4csTXK8ywpOcrpn79cOrMBbEX1Im3VbMgIZOtSU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=T2oyc0pW8/0KYN2otO5fmwNoL91T63Z7kSTldoR0JC1oodJl25tYGTHWaYI7AoBgy J5U8BLBu1S6yxXRCy1tq0t8s+GJxqRyAt/CW4CMPX64GDD/W7Bz2dsMRkOMgSQwOa8 6pn+S6BCnCYZRtJHoBDZj7IijSDMe+5Y7YHmxj98= Message-ID: <0e305573-9046-4ecd-84f9-357cbc82449f@arm.com> Date: Thu, 28 May 2026 10:47:09 +0100 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] sched/deadline: Exclude special DL entities from bandwidth moves To: Guopeng Zhang , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot Cc: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , linux-kernel@vger.kernel.org, Guopeng Zhang References: <20260528065324.1303334-1-guopeng.zhang@linux.dev> Content-Language: en-US From: Christian Loehle In-Reply-To: <20260528065324.1303334-1-guopeng.zhang@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/28/26 07:53, Guopeng Zhang wrote: > From: Guopeng Zhang > > SUGOV special DL entities use fake/unused bandwidth. They are already > excluded from regular DL admission control, affinity admission checks, > rq bandwidth accounting, and root-domain rebuild accounting. > > dl_task_needs_bw_move() misses the same exclusion. As a result, > set_cpus_allowed_dl() and cpuset attach may treat a special DL entity as > requiring a root-domain bandwidth move when its affinity mask no longer > intersects the source root domain. > > Return false for special DL entities so root-domain bandwidth move > accounting follows the rest of the SUGOV special-entity handling. > > Signed-off-by: Guopeng Zhang > --- > kernel/sched/deadline.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index ddfd6bc63ab1..3653166caa69 100644 > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -3142,7 +3142,7 @@ static void set_cpus_allowed_dl(struct task_struct *p, > bool dl_task_needs_bw_move(struct task_struct *p, > const struct cpumask *new_mask) > { > - if (!dl_task(p)) > + if (!dl_task(p) || dl_entity_is_special(&p->dl)) > return false; > > return !cpumask_intersects(task_rq(p)->rd->span, new_mask); FWIW I don't see an issue excluding sugov here: Reviewed-by: Christian Loehle