hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

sched/swait: Document it clearly that the swait facilities are special and shouldn't be used 

We currently welcome using swait over wait whenever possible because
it is a slimmer data structure. However, Linus has made it very clear
that he does not want this used, unless under very specific RT scenarios
(such as current users).

Update the comments before kernel hipsters start thinking swait is the
cool thing to do.

Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dave@stgolabs.net
Cc: wagi@monom.org
Link: http://lkml.kernel.org/r/20171020171346.24445-1-dave@stgolabs.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Davidlohr Bueso 2017-10-20 10:13:46 -07:00 committed by Ingo Molnar
parent bb176f6709
commit 88796e7e5c
1 changed files with 16 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
include/linux/swait.h
View File

@ -9,13 +9,16 @@
/* /*
* Simple wait queues * Simple wait queues
* *
* While these are very similar to the other/complex wait queues (wait.h) the * While these are very similar to regular wait queues (wait.h) the most
* most important difference is that the simple waitqueue allows for * important difference is that the simple waitqueue allows for deterministic
* deterministic behaviour -- IOW it has strictly bounded IRQ and lock hold * behaviour -- IOW it has strictly bounded IRQ and lock hold times.
* times.
* *
* In order to make this so, we had to drop a fair number of features of the * Mainly, this is accomplished by two things. Firstly not allowing swake_up_all
* other waitqueue code; notably: * from IRQ disabled, and dropping the lock upon every wakeup, giving a higher
* priority task a chance to run.
*
* Secondly, we had to drop a fair number of features of the other waitqueue
* code; notably:
* *
* - mixing INTERRUPTIBLE and UNINTERRUPTIBLE sleeps on the same waitqueue; * - mixing INTERRUPTIBLE and UNINTERRUPTIBLE sleeps on the same waitqueue;
* all wakeups are TASK_NORMAL in order to avoid O(n) lookups for the right * all wakeups are TASK_NORMAL in order to avoid O(n) lookups for the right
@ -24,12 +27,14 @@
* - the exclusive mode; because this requires preserving the list order * - the exclusive mode; because this requires preserving the list order
* and this is hard. * and this is hard.
* *
* - custom wake functions; because you cannot give any guarantees about * - custom wake callback functions; because you cannot give any guarantees
* random code. * about random code. This also allows swait to be used in RT, such that
* raw spinlock can be used for the swait queue head.
* *
* As a side effect of this; the data structures are slimmer. * As a side effect of these; the data structures are slimmer albeit more ad-hoc.
* * For all the above, note that simple wait queues should _only_ be used under
* One would recommend using this wait queue where possible. * very specific realtime constraints -- it is best to stick with the regular
* wait queues in most cases.
*/ */
struct task_struct; struct task_struct;