From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 89D0A35DD1C for ; Mon, 1 Jun 2026 13:48:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780321738; cv=none; b=cPqujVdzzfF2eFt3X8D1CYZAZbmQD0LZLyFjfR/aXpqkPHv830fFOtG2eylE+Fv88Ja99EbrwlVLfB10uWPLRm9440M2RBJtjf7A045NPs4zeQFwwn5ttwM5PdJLr2GUJ08SymvMaAM0VzyIutQY+Fuouxgn8DXblzePimek1F8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780321738; c=relaxed/simple; bh=tH0DdZz5OX6rsWY1gMAGhuDnD/PIMQlbLeVNZD4vGxM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UWA53XchoTAMD8jdIw04XEWlZYz69TgA78wwiOxJgv0remB3dRomTFSFLwht2NPpz/DzaQJS6+9g0xWdsVIODYBo6VkKhO6k7sR9WlS7GHH+NwwOMl/TACLqdJ/NR17U2aN611hbVGS0fW5+3fxrYeOcFlZd8gxLw6jZzAySrzU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=mccssZ2B; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="mccssZ2B" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=NoDJS5Wf1z43UFXxiEAPxPSh92t7atBoofIXVMQQ7Go=; b=mccssZ2BrYc07CErJy2Wn9PDUB 2CArJAJB7ICz1vB6T0U+Pu7Ii13azbtuskyS2JND7mBoSIpStOAfyRZYSUHGpC4zCYArzkO9NLb3S GdfyBd2MkIngSEaaqP4Q9QE1cShAmX401VRqS6XcdlWwXYjtpxKeW3kEH5MPQnSGyf5CVGcdWSevL KmBvCyPtq1p7VwiZy/3Rc10H/ySDF11N1kQJYBBYYLJKh03TguPWsVnC5Y3wHH3YikK1E8jD/5yZn M1D401R/pImEdVCJEwVRRHIeBarejUISrI7XmkXQDW9+7SNlSyJ6+chlZUgZsQhjWcYwrnXSfGrt9 cpfRFqtg==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wU30V-00000006qhi-0sOz; Mon, 01 Jun 2026 13:48:44 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 6A04D300642; Mon, 01 Jun 2026 15:48:42 +0200 (CEST) Date: Mon, 1 Jun 2026 15:48:42 +0200 From: Peter Zijlstra To: K Prateek Nayak Cc: Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Aaron Lu , Josh Don , linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/5] sched/fair: Unify cfs_rq throttling via account_cfs_rq_runtime() Message-ID: <20260601134842.GP343181@noisy.programming.kicks-ass.net> References: <20260528094830.13291-1-kprateek.nayak@amd.com> <20260528094830.13291-6-kprateek.nayak@amd.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260528094830.13291-6-kprateek.nayak@amd.com> On Thu, May 28, 2026 at 09:48:30AM +0000, K Prateek Nayak wrote: > @@ -9893,8 +9882,15 @@ static struct task_struct *pick_task_fair(struct rq *rq, struct rq_flags *rf) > /* Might not have done put_prev_entity() */ > if (cfs_rq->curr && cfs_rq->curr->on_rq) > update_curr(cfs_rq); > - > - throttled |= check_cfs_rq_runtime(cfs_rq); > + /* > + * For the current hierarchy, update_curr() above would > + * have set the throttle indicators if the cfs_rq has > + * run out of bandwidth. For others, enqueue / last > + * update_curr() for the cfs_rq would have ensured the > + * throttle indicators are set if bandwidth was not > + * available. > + */ > + throttled |= cfs_rq_throttled(cfs_rq); > > se = pick_next_entity(rq, cfs_rq, true); > if (!se) > @@ -15074,15 +15070,19 @@ static void __set_next_task_fair(struct rq *rq, struct task_struct *p, bool firs > static void set_next_task_fair(struct rq *rq, struct task_struct *p, bool first) > { > struct sched_entity *se = &p->se; > + bool throttled = false; > > for_each_sched_entity(se) { > struct cfs_rq *cfs_rq = cfs_rq_of(se); > > set_next_entity(cfs_rq, se, first); > /* ensure bandwidth has been allocated on our new cfs_rq */ > - account_cfs_rq_runtime(cfs_rq, 0); > + throttled |= account_cfs_rq_runtime(cfs_rq, 0); > } > > + if (throttled) > + task_throttle_setup_work(p); > + > __set_next_task_fair(rq, p, first); > } (noticed while trying to rebase flat on top) Why do we have both? Isn't just set_next_task_fair(.first=true) sufficient?