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

[Tejun Heo <tj@kernel.org>]

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?

Thanks.

--
tejun