Re: [PATCH 2/4] swait: add the missing killable swaits
From: Marcelo Tosatti
Date: Thu Jun 29 2017 - 22:37:28 EST
On Thu, Jun 29, 2017 at 09:13:29AM -0700, Linus Torvalds wrote:
> On Thu, Jun 29, 2017 at 6:46 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> > On Thu, 29 Jun 2017, Greg KH wrote:
> >> On Thu, Jun 29, 2017 at 03:05:26PM +0200, Thomas Gleixner wrote:
> >> >
> >> > And who defined that it should not be used in real code?
> >>
> >> Linus did, in a different firmware thread. You have to _really_ know
> >> what you are doing to use this interface, and the firmware interface
> >> shouldn't be using it. So adding new apis just for firmware does not
> >> seem like a wise decision at this point in time.
> >
> > So it's not about code in general, it's about a particular piece of
> > code. Fair enough.
>
> Well, I'd actually say it the other way around: swait should not be
> used in general, only in _very_ particular pieces of code that
> actually explicitly need the odd swait semantics.
>
> swait uses special locking and has odd semantics that are not at all
> the same as the default wait queue ones. It should not be used without
> very strong reasons (and honestly, the only strong enough reason seems
> to be "RT").
Performance shortcut:
https://lkml.org/lkml/2016/2/25/301
> The special locking means that swait doesn't do DEBUG_LOCK_ALLOC, but
> it also means that it doesn't even work in all contexts.
>
> So "swake_up()" does surprising things (only wake up one - that's what
> caused a firmware loading bug), and "swake_up_all()" has magic rules
> about interrupt disabling.
>
> The thing is simply a collection of small hacks and should NOT be used
> in general.
Its a very smart performance speed up ;-)
> I never want to see a driver use that code, for example. It was
> designed for RCU and RT, and it should damn well be limited to that.
>
> Linus
If KVM is the only user, feel free to remove it, you're past the point
where that performance improvement matters (due to VMX hardware
improvements).