linux-kernel - Re: [PATCH V1] fuse: give wakeup hints to the scheduler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Ya86coKm4RuQDmVS@hirez.programming.kicks-ass.net>
Date:   Tue, 7 Dec 2021 11:41:54 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Miklos Szeredi <miklos@...redi.hu>
Cc:     Ingo Molnar <mingo@...hat.com>, quic_stummala@...cinc.com,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        quic_pkondeti@...cinc.com, quic_sayalil@...cinc.com,
        quic_aiquny@...cinc.com, quic_zljing@...cinc.com,
        quic_blong@...cinc.com, quic_richardp@...cinc.com,
        quic_cdevired@...cinc.com,
        Pradeep P V K <quic_pragalla@...cinc.com>
Subject: Re: [PATCH V1] fuse: give wakeup hints to the scheduler

On Tue, Dec 07, 2021 at 11:20:59AM +0100, Miklos Szeredi wrote:
> On Tue, 7 Dec 2021 at 11:07, Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > On Tue, Dec 07, 2021 at 10:07:45AM +0100, Miklos Szeredi wrote:
> > > On Mon, 6 Dec 2021 at 09:47, Pradeep P V K <quic_pragalla@...cinc.com> wrote:
> > > >
> > > > The synchronous wakeup interface is available only for the
> > > > interruptible wakeup. Add it for normal wakeup and use this
> > > > synchronous wakeup interface to wakeup the userspace daemon.
> > > > Scheduler can make use of this hint to find a better CPU for
> > > > the waker task.
> >
> > That's a horrendoubly bad changelog :-/ Also, if you need it for
> > UNINTERRUPTIBLE that's trivial to do ofc.
> >
> > > Ingo, Peter,
> > >
> > > What exactly does WF_SYNC do?   Does it try to give the waker's CPU
> > > immediately to the waked?
> > >
> > > If that doesn't work (e.g. in this patch the wake up is done with a
> > > spin lock held) does it do anything?
> > >
> > > Does it give a hint that the waked task should be scheduled on this
> > > CPU at the next scheduling point?
> >
> > WF_SYNC is a hint to the scheduler that the waker is about to go sleep
> > and as such it is reasonable to stack the woken thread on this CPU
> > instead of going to find an idle CPU for it.
> >
> > Typically it also means that the waker and wakee share data, and thus
> > having them share the CPU is beneficial for cache locality.
> 
> Okay, so it doesn't give up the CPU immediately to the woken task,
> just marks the woken task as a "successor" when the current task goes
> to sleep.  Right?

More or less.

> That may be good for fuse as the data is indeed shared.  It would be
> even better if the woken task had already a known affinity to this
> CPU, since that would mean thread local data wouldn't have to be
> migrated each time...   So I'm not sure sync wakeup alone is worth it,
> needs real life benchmarking.

Hard affinities have other down-sides.. occasional migrations shouldn't
be a problem, constant migrations are bad.