linux-kernel - Re: [PATCH 2/2] sched/fair: Reimplement NEXT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251114121349.GG4067720@noisy.programming.kicks-ass.net>
Date: Fri, 14 Nov 2025 13:13:49 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Mel Gorman <mgorman@...hsingularity.net>
Cc: Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Valentin Schneider <vschneid@...hat.com>,
	Chris Mason <clm@...a.com>,
	Madadi Vineeth Reddy <vineethr@...ux.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] sched/fair: Reimplement NEXT_BUDDY to align with
 EEVDF goals

On Thu, Nov 13, 2025 at 09:04:38AM +0000, Mel Gorman wrote:
> On Wed, Nov 12, 2025 at 03:48:23PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 12, 2025 at 12:25:21PM +0000, Mel Gorman wrote:
> > 
> > > +	/* Prefer picking wakee soon if appropriate. */
> > > +	if (sched_feat(NEXT_BUDDY) &&
> > > +	    set_preempt_buddy(cfs_rq, wake_flags, pse, se)) {
> > > +
> > > +		/*
> > > +		 * Decide whether to obey WF_SYNC hint for a new buddy. Old
> > > +		 * buddies are ignored as they may not be relevant to the
> > > +		 * waker and less likely to be cache hot.
> > > +		 */
> > > +		if (wake_flags & WF_SYNC)
> > > +			preempt_action = preempt_sync(rq, wake_flags, pse, se);
> > > +	}
> > 
> > Why only do preempt_sync() when NEXT_BUDDY? Nothing there seems to
> > depend on buddies.
> 
> There isn't a direct relation, but there is an indirect one. I know from
> your previous review that you separated out the WF_SYNC but after a while,
> I did not find a good reason to separate it completely from NEXT_BUDDY.
> 
> NEXT_BUDDY updates cfs_rq->next if appropriate to indicate there is a waker
> relationship between two tasks and potentially share data that may still
> be cache resident after a context switch. WF_SYNC indicates there may be
> a strict relationship between those two tasks that the waker may need the
> wakee to do some work before it can make progress. If NEXT_BUDDY does not
> set cfs_rq->next in the current waking context then the wakee may only be
> picked next by coincidence under normal EEVDF rules.

Aah, fair enough. Perhaps the comment could've been clearer but
whatever.