Re: [PATCH 2/2] sched/fair: Reimplement NEXT_BUDDY to align with EEVDF goals

[Peter Zijlstra <peterz@infradead.org>]

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.