Re: [PATCH v2 04/12] sched/core: Make __update_rq_clock() skip updates on UPDATED

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Nov 11, 2026 at 11:28:17AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 10, 2026 at 03:11:28PM -1000, Tejun Heo wrote:
> > Hello, Peter.
> > 
> > On Sat, Nov 07, 2026 at 12:59:17PM +0100, Peter Zijlstra wrote:
> > >  static void __update_rq_clock(struct rq *rq)
> > >  {
> > > +	bool update;
> > > +
> > >  	lockdep_assert_rq_held(rq);
> > >  
> > > +	update = !(rq->clock_update_flags & RQCF_NOP_MASK);
> > >  	rq->clock_update_flags |= RQCF_UPDATED;
> > >  
> > > -	if (!(rq->clock_update_flags & RQCF_ACT_SKIP)) {
> > > +	if (update) {
> > 
> > RQCF_UPDATED is cleared only by rq_pin_lock() and
> > double_rq_clock_clear_update(), so a path which takes the rq lock with
> > raw_spin_rq_lock() inherits it from the previous holder and its
> > update_rq_clock() is now silently skipped.
> 
> Let me look at that specific case.
> 
> > Previously, you said to clear on unlock. Why not do that? That'd be less
> > confusing overall.
> 
> Yes, that's what I tried, but it doesn't work for core-sched. What
> happens is that SMT0 and SMT1 interleave and things go to hell, patch 6
> has that picture.
> 
> That is, we can still clear on unlock too, but clear on unlock alone
> isn't sufficient :/
> 
> Patch 6 even has the clear on unlock, but commented out.

Right, so the complication is that for core I want the rq-clock to be
'frozen' over the rq-lock drop.

Notably, I want dequeue and pick / set-next to have the same timestamp
such that the whole of schedule appears to happen at one instant in
time.

For ext you've explicitly chosen to not do so, per the placement of
scx_rq_clock_invalidate().

The consequence is that the raw_spin_rq_lock() functions must remain
independent of rq_clock management; otherwise we cannot drop rq-lock
while keeping time frozen.

This means the rq-clock management must live in {pin,drop,repin,unpin};
and at that point, I didn't really see an advantage in doing it at
unpin.