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 ABC4C3955CF for ; Mon, 1 Jun 2026 11:28:05 +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=1780313287; cv=none; b=jnB1YJDzbDVCe+VNDg2S6xzEqfn7rdT/YvB5M3JZpD3z0HZjqngxTGVyCkAJ6ekhgtjToLNmK24TVpdCdHZsbtQF0ZxG6OHForIrfQW6uXFJWeJemQ1nZgCsmAW65prryXT1ThklGFMhPEf8gNvdX+AtLAMlr6kmfB/yxI7jhug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780313287; c=relaxed/simple; bh=9qGwNFh4tTTTDO4Ipq6SxLLo0+YfRFdJL1FGcsmVq/o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bOcd2ex4zRzJTW+wawLQUdqy/Iw7xSBopJeURcQL+YV7vlI3LDzHDzhNXfHKBF53ZYhISzxFNLyPtim2MphTJSU9QsIfwpwkxR55Pvg9CrQOYz3XENHDjYUcVQPupqiEnGIkB2UezvDZAGkfR/xnEETCwcQASGoUQM6FgI5psgU= 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=GW+1Ag3H; 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="GW+1Ag3H" 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=X3h9MmOfh1dY04VFxjIOW9nJYImomYPmGJPNvQuDz/g=; b=GW+1Ag3HALQ6IxID0gYr8z3Jdo I+LTaDf0cKN0FGv9eZ6dFCJ1qFlkVpJ2gryz4eKRRy/mXQ7AUyGYZyJQT1UQs1Dd4F8eY+63fQx4U 3us+UBeaLX6OV7m5RWOAQeKTpNm7/ywa0vNQkvN+ElM1+Qa5zpVkuvsu8mcf/GSjb3C0nQgX2B+LX 4RHh1Pq3hWV0AW6qlWOMBjkAqwNEGAChr9RguAInM1GzQAPyqU2ejD42WNjBzRR5lgkU6h86A0mvC XUX2VSXTsOc5dqhmuFTbjl0xKSptbxi/7MiPelI4RAFDfTDVRVrVIpwg1OodVU7shHxFAxkGvhScV LQjF6P+Q==; 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 1wU0oG-00000006X4O-05IA; Mon, 01 Jun 2026 11:27:56 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id B39DE300454; Mon, 01 Jun 2026 13:27:52 +0200 (CEST) Date: Mon, 1 Jun 2026 13:27:52 +0200 From: Peter Zijlstra To: K Prateek Nayak Cc: Aaron Lu , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Josh Don , linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/5] sched/fair: Call update_curr() before unthrottling the hierarchy Message-ID: <20260601112752.GR3493090@noisy.programming.kicks-ass.net> References: <20260528094830.13291-1-kprateek.nayak@amd.com> <20260528094830.13291-4-kprateek.nayak@amd.com> <20260601035201.GA690044@bytedance.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: On Mon, Jun 01, 2026 at 11:20:30AM +0530, K Prateek Nayak wrote: > Hello Aaron, > > On 6/1/2026 9:22 AM, Aaron Lu wrote: > >> Since all callers of unthrottle_cfs_rq(), except one, already update the > >> rq_clock and call rq_clock_start_loop_update(), move the > >> update_rq_clock() in unthrottle_cfs_rq() to the lonely caller that > >> doesn't update the rq_clock. > > > > Looks like there is one more path that doesn't have clock updated: > > cpu_max_write() -> tg_set_bandwidth() -> tg_set_cfs_bandwidth() -> > > unthrottle_cfs_rq(). > > Woops! Completely missed that. Thank you for pointing it out. I'll > add an update_rq_clock() there too once we grab the rq_lock. Like this? --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -9830,6 +9830,7 @@ static int tg_set_cfs_bandwidth(struct t struct rq *rq = cfs_rq->rq; guard(rq_lock_irq)(rq); + update_rq_clock(); cfs_rq->runtime_enabled = runtime_enabled; cfs_rq->runtime_remaining = 1;