From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 8C178395D8E for ; Mon, 30 Mar 2026 19:11:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774897889; cv=none; b=PnOgKdBEzGIJxBALe0x03nF0Xp7oEf2g8JzwXZ3FTjSlndnxdYKsszRKG2RaGehL5uIY5uj6gtzW+uKom5YmdmZFCQO3G66IFRI0f82ky9H1EqxgNtCYp0rFKbFeuPdnBg54IyaIPeIuOEzPc27AwUzRm1jw4tc6BLUTNRVEAZ0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774897889; c=relaxed/simple; bh=W6u0FpgbbLaHOCCGt+snxr0gXkmc13e/w+A10hA4XGI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aBJcwJxl+kuYYJMjBjdCqDWybBtSjV95FBUiNfSpbQwvPmCTteEhR38JBjA6KkHO0ZQgMcygBa3c/p8PL7j9RRrpR/IgWFO35WLz0bMxG9l6JQB/tpBzJy6/eyzNfbJuNsjm/df3Xj+hNOErDKjJ4KtvSjFj3ey/y8nq012AQTk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=q3mcCJvr; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none 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="q3mcCJvr" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=eF/bBprCNLRoisCIjm//ppF/boIQuoe5e7Hs8VWfJ1o=; b=q3mcCJvreqAf6DIdfX7qfNvM82 h/PmTIXaQSOxpv8eFRJI8YRGqVndgjn1nZUmzZRBP6tyu/yOGpna11+PcJUvQK1QsN8MbWfr4n8Rp EcZZSrKplJgqM/ISPVEVpu09DZKBklYh7j8oW8/tKly9UAd+p065PU2/OHuw/Ex56SP32du8eoC6B aTtDBAYn7TI6sydR6aSCFy4zGbQ1TzQxrafsDY8KbZh9HalkHi5pWTpB8ljLsPsEqvB0vMnPC3Irg nwG0FEwZAEzbV2D++tcgIydPt15Z60995RsVo1T0iI1twblKKLotoH3307PROJRvEINkryhhaEsaZ gEAVVCsw==; Received: from 2001-1c00-8d85-4b00-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:4b00:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w7I10-00000007Ar8-19Yd; Mon, 30 Mar 2026 19:11:10 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id C4D7230057E; Mon, 30 Mar 2026 21:11:08 +0200 (CEST) Date: Mon, 30 Mar 2026 21:11:08 +0200 From: Peter Zijlstra To: K Prateek Nayak Cc: John Stultz , mingo@kernel.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, linux-kernel@vger.kernel.org, wangtao554@huawei.com, quzicheng@huawei.com, dsmythies@telus.net, shubhang@os.amperecomputing.com, Suleiman Souhlal Subject: Re: [PATCH v2 1/7] sched/fair: Fix zero_vruntime tracking Message-ID: <20260330191108.GU2872@noisy.programming.kicks-ass.net> References: <20260219075840.162631716@infradead.org> <20260219080624.438854780@infradead.org> <20260330101018.GN3738786@noisy.programming.kicks-ass.net> <73dab51a-650f-4c82-9e73-13236b2a26c2@amd.com> <20260330144005.GP3738786@noisy.programming.kicks-ass.net> 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, Mar 30, 2026 at 09:20:01PM +0530, K Prateek Nayak wrote: > Hello Peter, > > On 3/30/2026 8:10 PM, Peter Zijlstra wrote: > > On Mon, Mar 30, 2026 at 08:07:06PM +0530, K Prateek Nayak wrote: > >> Hello Peter, > >> > >> On 3/30/2026 3:40 PM, Peter Zijlstra wrote: > >>> This means, that if the two tasks playing leapfrog can reach the > >>> critical speed to reach the overflow point inside one tick's worth of > >>> time, we're up a creek. > >>> > >>> If this is indeed the case, then the below should cure things. > >> > >> I have been running with this for four hours now and haven't seen > >> any splats or crashes on my setup. I could reliably trigger the > >> warning from __sum_w_vruntime_add() within an hour previously so > >> it is safe to say I was hitting exactly this. > >> > >> Feel free to include: > >> > >> Tested-by: K Prateek Nayak > > > > Ha!, excellent. Thanks! > > Turns out I spoke too soon and it did eventually run into that > problem again and then eventually crashed in pick_task_fair() > later so there is definitely something amiss still :-( > > I'll throw in some debug traces and get back tomorrow. Are there cgroups involved? I'm thinking that if you have two groups, and the tick always hits the one group, the other group can go a while without ever getting updated. But if there's no cgroups, this can't be it. Anyway, something like the below would rule this out I suppose. diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index bf948db905ed..19b75af31a5a 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1304,6 +1304,8 @@ static void update_curr(struct cfs_rq *cfs_rq) curr->vruntime += calc_delta_fair(delta_exec, curr); resched = update_deadline(cfs_rq, curr); + if (resched) + avg_vruntime(cfs_rq); if (entity_is_task(curr)) { /* @@ -5593,11 +5595,6 @@ entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr, int queued) update_load_avg(cfs_rq, curr, UPDATE_TG); update_cfs_group(curr); - /* - * Pulls along cfs_rq::zero_vruntime. - */ - avg_vruntime(cfs_rq); - #ifdef CONFIG_SCHED_HRTICK /* * queued ticks are scheduled to match the slice, so don't bother