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 93DBE36A009 for ; Tue, 24 Feb 2026 09:03:02 +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=1771923786; cv=none; b=iSwv6UPCQM4MqLyur2ZSmwcePDmgmfTp4ECbyFsk7DFhHyJBFl2k33lCejajjqQ5k/SfhR86uggxKxYCN+1e97xc7IChQ4sVj+7/GoK5YEhTLTA2yeLnxJKJC4b4SL7iIEx3pDwPeLkaT/8SNGW9jpwPlpD53IZhWED/MIv0c00= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771923786; c=relaxed/simple; bh=lVcSp3n9x05s/nJq82Op+hVk/LBjTqy7pmZxBW/bVJU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rAlh3+z+V/EymsSOI3FaFR9Z2vT6v7of2KSPCSzoprHQovfcgIQwd+6aZLSpfW2bGMM3npuWQ8cQgSNfIZsPnhRyZqtWubRSaUYRIae/0RCRPg9hAIaaeerS55iGObjfAgKFQhR7jG4ZS6c5OJzBqWLIFoAecDu2S7Juu+5Z4wY= 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=RNFytKZo; 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="RNFytKZo" 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=AD03Q7rhYqjOfXivdab6Otcdbt4TZtRr1QX8QuPxxN4=; b=RNFytKZo75c0azx9M5RfUvZne8 UOu0CZldWhaj5egAP2RHIgAMS75lbW7M/a2l28fkjq1/pQRdDi0RUmQX9Tv75fpXuJiOsShadIgjN gU2ljZT7TkN+Jls/trvjjY/7Pzic/hAx/plyi3r1GP/XfrLpsBTFIqIOUAs8Et28gtl2z+yw/17mE R8yS0dVZP+fcyHMU5GDLWzoEBUM9rvakgFnmwP/Vi2UFM0jkkslwmk9pnyHQ29ULm9Oi3A/kS96lx PdXHfQYth95fB6bVIf0rflVy3czcLKSK2bUxvfYLIpdDPftGRb4t4MiZCO5DtXraR6s4NvaTBjMsi 1DqL/U1A==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700: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 1vuoJe-0000000Fy4N-2sC1; Tue, 24 Feb 2026 09:02:50 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 23D40300882; Tue, 24 Feb 2026 10:02:49 +0100 (CET) Date: Tue, 24 Feb 2026 10:02:49 +0100 From: Peter Zijlstra To: Dietmar Eggemann Cc: mingo@kernel.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, linux-kernel@vger.kernel.org, wangtao554@huawei.com, quzicheng@huawei.com, kprateek.nayak@amd.com, dsmythies@telus.net, shubhang@os.amperecomputing.com Subject: Re: [PATCH v2 1/7] sched/fair: Fix zero_vruntime tracking Message-ID: <20260224090249.GV1395266@noisy.programming.kicks-ass.net> References: <20260219075840.162631716@infradead.org> <20260219080624.438854780@infradead.org> <20260223141513.GQ1282955@noisy.programming.kicks-ass.net> <41fce66a-3bf8-458e-872d-845713c19721@arm.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: <41fce66a-3bf8-458e-872d-845713c19721@arm.com> On Tue, Feb 24, 2026 at 09:53:06AM +0100, Dietmar Eggemann wrote: > On 23.02.26 15:15, Peter Zijlstra wrote: > > On Mon, Feb 23, 2026 at 02:09:52PM +0100, Dietmar Eggemann wrote: > >> On 19.02.26 08:58, Peter Zijlstra wrote: > >>> It turns out that zero_vruntime tracking is broken when there is but a single > >>> task running. Current update paths are through __{en,de}queue_entity(), and > >>> when there is but a single task, pick_next_task() will always return that one > >>> task, and put_prev_set_next_task() will end up in neither function. > >> > >> Tried hard but I don't get the last clause. > > > > When prev==next, then put_prev_set_next_task() bails out and we'll never > > hit __enqueue_entity()/__dequeue_entity(). > > Ah, I see. But IMHO put_prev_set_next_task() is never called for the > testcase below (CPU hog is prev and next in put_prev_set_next_task()) > > But (prev != p) in pick_next_task_fair() is avoided ? > > pick_next_task_fair() > > if (prev != p) { > > while (!is_same_group()) > put_prev_entity() > set_next_entity() > > put_prev_entity() > set_next_entity() > } > Ah yes, pick_next_task_fair() open codes that. Also, I might have a patch to 'fix' all that, but I've not goten around to posting that. There's still a few wobblies in that part of the pile :/ Look at the top 3 patches in queue/sched/flat if you're up for it :-)