Why doesn't Linux have a NORCU RCU option that just implements the RCU API as plain rwlocks?
But I don't think this is solvable in Linux. The code using the RCU api actually does the alloc/free operations...
-
-
...so there's no way a "NORCU" (as plain rwlock) could give you update-in-place without unwanted invasive changes.
-
That is correct. A NORCU has the same problem in user mode in the presence of signal handlers.
-
That's trivial to solve in kernel because disabling irqs takes at most a couple cycles. OTOH sigprocmask is syscall.
-
BTW any tips on debugging RCU stalls (not perm, just long, >20s) in idle task with dyntick? :-)
-
(1) https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt … (2) but please email me dmesg + .config + version
-
New SoC support going upstream, stalls introduced by Linus's in-progress-merge-window pulls. Want to find/report/fix.
-
I've read that doc but it's not helping me figure out why the stall is happening. Guess is bad timing of infreq wakes
-
Please email me dmesg+.config+version (for example, SHA1). Maybe someone broke something, maybe me. :-)
- 2 more replies
New conversation -
-
-
Any chance of a clear statement of what you believe the problem to be? :-)
-
Aside from overall complexity cost, the fact that RCU users have to alloc/free data that otherwise would be perm.
-
This makes it near-impossible to guard against catastrophic failure on OOM (needs difficult & costly accounting).
-
The stall warning you encountered is part of that accounting.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.