kernel_5.10 no rt

hc

2023-12-11 6778948f9de86c3cfaf36725a7c87dcff9ba247f

 kernel/include/linux/swait.h
..
..
@@ -9,23 +9,10 @@
9
9
 #include <asm/current.h>
10
10
 
11
11
 /*
12
- * BROKEN wait-queues.
13
- *
14
- * These "simple" wait-queues are broken garbage, and should never be
15
- * used. The comments below claim that they are "similar" to regular
16
- * wait-queues, but the semantics are actually completely different, and
17
- * every single user we have ever had has been buggy (or pointless).
18
- *
19
- * A "swake_up_one()" only wakes up _one_ waiter, which is not at all what
20
- * "wake_up()" does, and has led to problems. In other cases, it has
21
- * been fine, because there's only ever one waiter (kvm), but in that
22
- * case gthe whole "simple" wait-queue is just pointless to begin with,
23
- * since there is no "queue". Use "wake_up_process()" with a direct
24
- * pointer instead.
25
- *
26
- * While these are very similar to regular wait queues (wait.h) the most
27
- * important difference is that the simple waitqueue allows for deterministic
28
- * behaviour -- IOW it has strictly bounded IRQ and lock hold times.
12
+ * Simple waitqueues are semantically very different to regular wait queues
13
+ * (wait.h). The most important difference is that the simple waitqueue allows
14
+ * for deterministic behaviour -- IOW it has strictly bounded IRQ and lock hold
15
+ * times.
29
16
  *
30
17
  * Mainly, this is accomplished by two things. Firstly not allowing swake_up_all
31
18
  * from IRQ disabled, and dropping the lock upon every wakeup, giving a higher
..
..
@@ -39,7 +26,7 @@
39
26
  *    sleeper state.
40
27
  *
41
28
  *  - the !exclusive mode; because that leads to O(n) wakeups, everything is
42
- *    exclusive.
29
+ *    exclusive. As such swake_up_one will only ever awake _one_ waiter.
43
30
  *
44
31
  *  - custom wake callback functions; because you cannot give any guarantees
45
32
  *    about random code. This also allows swait to be used in RT, such that