[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ya8ycLODlcvLx4xB@hirez.programming.kicks-ass.net>
Date: Tue, 7 Dec 2021 11:07:44 +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 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.
That said, WF_SYNC is 'difficult' since not all users of the hint keep
their promise, so there's a bit of heuristics sprinkled on :/
Powered by blists - more mailing lists