Re: [PATCH v2 00/12] sched: core-sched fixes and balancing

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Nov 11, 2026 at 01:46:16AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Sat, Nov 07, 2026 at 12:59:13PM +0100, Peter Zijlstra wrote:
> > The main difference is reworking of rq_clock due to TJ noticing the previous
> > one got it all wrong. The new patches might seem a little aimless at times;
> > this is because my initial idea for fixing the problem didn't pan out, but I
> > kept some of the groundwork for it anyway, since it resulted in simpler (I
> > hope) code.
> 
> I wonder whether the clock management is too subtle, and as Kayra
> pointed out on 05/12, saving and restoring the flags doesn't work when
> lock sections straddle each other, which core-sched makes common.
> Stepping back, I think the clock needs only two things:
> 
> 1. The wakeup path wants the following clock update to be skipped. This
>    doesn't need the REQ/ACT handoff. It can be one bit which says
>    "whoever updates the clock next, consider it updated without reading
>    it", cleared at the end of __schedule() so that it doesn't leak past
>    the reschedule that it was meant for.
> 
> 2. The clock should stay put across a section including while the lock
>    is dropped in the middle. This can be a per-rq depth count.
>    rq_pin_lock() increments, rq_unpin_lock() decrements, and
>    rq_drop_lock() and rq_repin_lock() don't touch it. update_rq_clock()
>    reads the clock only if it hasn't since the count left zero, and
>    that state is cleared when the count returns to zero, which is the
>    clear on unlock. Whoever locks the rq while a section is dropped
>    comes in at depth two and finds the clock already updated, so there's
>    no separate freeze state and nothing to save and restore, and it
>    doesn't matter in which order the sections end.
> 
> Raw lockers don't hold a count, so they'd update each time when no
> section is open, and double_rq_clock_clear_update() can go away. For
> core-sched, the core-wide selection updates every sibling's clock
> anyway, so it can take a count on each sibling as it does that and drop
> them when the selection ends.
> 
> What do you think?

Yeah, let me to play around with all that.