[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjHgkama3SYOcYCYt_F-sxV8h4+kQ5aQSMgK7PtiQ=Nkw@mail.gmail.com>
Date: Tue, 26 May 2020 14:41:03 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Tejun Heo <tj@...nel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Lai Jiangshan <jiangshanlai@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 0/3] workqueue: Make the workqueue code PREEMPT_RT safe
On Tue, May 26, 2020 at 12:46 PM Tejun Heo <tj@...nel.org> wrote:
>
> No objection from workqueue side but the comment in swait.h doesn't look too
> encouraging. Kinda difficult to make a call from my side. Linus, does this
> qualify as the RT use case you had on mind?
I still find swait to be very questionable, but at least it has gotten
better over time.
Almost all users of swait have historically been buggy and/or
pointless. At least the naming disaster has been fixed, and the
outright bugs have hopefully been handled in the process. The
"pointless" part has been that people have used these swait lists for
single-entry queues, for absolutely no reason when just a task pointer
would have been the better model.
Honestly, that seems to be the case even for the workqueue code. Why
the h*ll do people insist on using wait queues - and then converting
them to swait queues - when there is only a single waiter (the pool
manager in this case).
I really don't understand this fundamental disconnect with reality.
You have a waitqueue with locking issues, and a _single_ waiter, and
what you do is convert this to swait.
WHY?
And no, the answer is not "swait is just so great". swait has
traditionally been a buggy misnamed disaster, and the fact that at
least now it's no longer using actively misleading naming any more
doesn't make it magically better than just "wake_up_process()".
Linus
Powered by blists - more mailing lists