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 9AE7E286415 for ; Mon, 2 Feb 2026 09:24:51 +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=1770024293; cv=none; b=AFFjs7rNeeNgWHgliy1zf0+qPGZqobwjOMowbbnp11kjEzOKZkPp8WwdKVHc3sAoGbZDqI+oukvPUwpG+ltiTzfMbh9tNjPRfxtAE0JNeIwlLxgxXAYSklOyGKlTc/zFHeczGx6FQ9DHSpzNlyoUVaQtBY1mqUr1p+fiEArMOhw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770024293; c=relaxed/simple; bh=l6qhk0rdsJdNHZ7VqtLOin0fb5KxBFbjD+IbtWrMBe0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=usHaLi/qbBw8YKOEKJmTzUQjJ/hnn0SuvuXM0ld3QGCF+R3YT2hqeltEc7zv5ZF4BNuiyma+yB6JVvhvvYJDsuzLKjnd+NAdRo1SxFACHgQu6VLkU5XtW8KE++5EsiUa5WdvErGspi+pUvA8hZC6rpkRbtVRKNh//QMXETjCG78= 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=VmTCXaYX; 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="VmTCXaYX" 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=RFNOJo8AKpavpbPlAYWrFZc1x50BEVcmBKdSlUaCmOI=; b=VmTCXaYXBqNzxhg4tBLDQdeuiy rFeD5kGcLNgBGBvwjNUK2SbjONxWN+KmmNJbIx3GYcrJ8sWOhVTUd/M3ViFQQEX1MR1GiufsMSFzj RXy+349Rm/D0rG1IToubUi6MXSux4TFqfuAsL3ZffCQJvG04+oBUkKHpy/FyAJ+msxBELEndpEbTi uM4tQ3+g0zwSsF4GB1SJZmw1qrglICUHjEPZNZOfjZ5Z3DsvAbmftTXvNbAB7mjDRVmdST8khqsJ3 AncITWgvCuq39vR117+T2m02y9el9bLUHEt6dcplHino+IFDmulgn0LaP2UUg1UdSZTehe9vw2w47 DyLNRjVw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vmqAd-0000000GH5Q-36yf; Mon, 02 Feb 2026 09:24:36 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 843B4303047; Mon, 02 Feb 2026 10:24:34 +0100 (CET) Date: Mon, 2 Feb 2026 10:24:34 +0100 From: Peter Zijlstra To: Zhang Qiao Cc: 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, kprateek.nayak@amd.com, wuyun.abel@bytedance.com, dsmythies@telus.net, Hui Tang Subject: Re: [PATCH 4/4] sched/fair: Revert 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag") Message-ID: <20260202092434.GB1395416@noisy.programming.kicks-ass.net> References: <20260130093439.803225718@infradead.org> <20260130094608.304041157@infradead.org> <716f3b5a-8a82-88e1-b684-4723882a0d6b@huawei.com> <20260131152135.GA509491@noisy.programming.kicks-ass.net> <20260202091234.GA1395416@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: <20260202091234.GA1395416@noisy.programming.kicks-ass.net> On Mon, Feb 02, 2026 at 10:12:34AM +0100, Peter Zijlstra wrote: > On Sat, Jan 31, 2026 at 04:21:39PM +0100, Peter Zijlstra wrote: > > On Sat, Jan 31, 2026 at 09:47:07AM +0800, Zhang Qiao wrote: > > > > > > if (se->on_rq) { > > > > /* commit outstanding execution time */ > > > > update_curr(cfs_rq); > > > > - update_entity_lag(cfs_rq, se); > > > > - se->deadline -= se->vruntime; > > > > + avruntime = avg_vruntime(cfs_rq); > > > > + se->vlag = entity_lag(avruntime, se); > > > > > > > > > vlag is updated here. Considering vlag and vprot share the same union, updating > > > vlag will overwrite vprot. Is it right to call protect_slice() (which use vprot) > > > after this update? > > > > Oh you are quite right; I'm sure Ingo had a patch removing that union, > > but clearly that's not been merged yet. > > > > Sorry about that mistake; I'll make a new version on Monday. > > After looking at things, I think the best option is to simply remove > that union. > > The thing is, I can fix reweight to respect this union, but there are > more problems, notably the sched_change pattern will not only call > put_prev_task/set_next_task, it will actually dequeue/enqueue the thing > and therefore 'temporarily' use the vlag field, destroying the vprot > value. > > And yes, we can fix all that, but I'm thinking that at that point the > union is more trouble than its worth. > And its already gone -- I managed to consistently look at the wrong tree. So all should be good. --- commit 80390ead2080071cbd6f427ff8deb94d10a4a50f Author: Ingo Molnar Date: Wed Nov 26 05:31:28 2025 +0100 sched/fair: Separate se->vlag from se->vprot There's no real space concerns here and keeping these fields in a union makes reading (and tracing) the scheduler code harder. Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20251201064647.1851919-4-mingo@kernel.org diff --git a/include/linux/sched.h b/include/linux/sched.h index d395f2810fac..bf96a7d595e2 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -586,15 +586,10 @@ struct sched_entity { u64 sum_exec_runtime; u64 prev_sum_exec_runtime; u64 vruntime; - union { - /* - * When !@on_rq this field is vlag. - * When cfs_rq->curr == se (which implies @on_rq) - * this field is vprot. See protect_slice(). - */ - s64 vlag; - u64 vprot; - }; + /* Approximated virtual lag: */ + s64 vlag; + /* 'Protected' deadline, to give out minimum quantums: */ + u64 vprot; u64 slice; u64 nr_migrations;