On Thu, Jun 29, 2017 at 09:13:29AM -0700, Linus Torvalds wrote:

On Thu, Jun 29, 2017 at 6:46 AM, Thomas Gleixner [off-list ref] wrote:

quoted

On Thu, 29 Jun 2017, Greg KH wrote:

quoted

On Thu, Jun 29, 2017 at 03:05:26PM +0200, Thomas Gleixner wrote:

quoted

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).