Re: [PATCH 02/20 v3] sched/eevdf: Reset lag at wakeup when prev CPU has been idle

[Vincent Guittot]

On Mon, 9 Nov 2026 at 16:45, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Mon, Nov 09, 2026 at 04:27:14PM +0100, Vincent Guittot wrote:
> > On Fri, 6 Nov 2026 at 17:22, Kayra Cizmeci <kayracizmeci@xxxxxxxxx> wrote:
> > >
> > > On Fri, Nov 06, 2026 at 04:19:29PM +0100, Vincent Guittot wrote:
> > > > @@ -8376,6 +8383,9 @@ static bool __dequeue_task(struct rq *rq, struct task_struct *p, int flags)
> > > >
> > > >       dequeue_hierarchy(p, flags);
> > > >
> > > > +     if (!(flags & DEQUEUE_SAVE) && !cfs_rq->h_nr_queued)
> > > > +             cfs_rq->idle_seq++;
> > >
> > > This needs WRITE_ONCE, no?  3/20 uses READ_ONCE().
> >
> > I hesistated to make it WRITE_ONCE but i concluded that it was not
> > strictly necessary because the READ_ONCE is only used to compare the
> > value but not use it for any computation or sync so if the compiler
> > wants to do any kind of optimization what we really care is : is it
> > equal or not ? so any intermediate value that we would read would be
> > ok
>
> Right, so without WRITE_ONCE() the compiler is allowed to write the word
> in random order byte writes. When comparing only cares about equality,
> any intermediate messed up state is not equal. And since we were
> incrementing, we're not supposed to be equal to any previous snapshot.
>
> Therefore all is well.
>
> That said; we should either document the above reasoning, or just do
> WRITE_ONCE() and get all the sanitizers off our back, because I'm
> certain that KCSAN is going to complain about this.

I agree that it needs at least a comment. I can use WRITE_ONCE but I
remember seeing somethign about its cost. But does it worth having
sanitizers complaining ... I will run some tests and use WRITE_ONCE if
I don't see difference