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). -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
