I'd ask @paulmckrcu
-
-
Replying to @jfbastien @RichFelker
We tried something like that some years back for realtime, but gave up on it due to deadlocks, IIRC.
1 reply 0 retweets 1 like -
Replying to @paulmckrcu @jfbastien
That's unfortunate. The "copy" part of RCU seems to make the whole kernel OOM-unsafe and prob. frag-unsafe for nommu.
2 replies 0 retweets 0 likes -
TREE_RCU "..is designed for very large SMP system with hundreds or thousands of CPUs...also scales down nicely.." No.
1 reply 0 retweets 0 likes -
Why does everybody love breaking the important real-world case (1-8 cores) for the sake of HPC wackiness? :-(
1 reply 0 retweets 0 likes -
Replying to @RichFelker @jfbastien
Lots of important real-world cases with a wide range of CPUs. You are doing mobile or some such?
1 reply 0 retweets 0 likes -
Replying to @paulmckrcu @jfbastien
Mobile and embedded. But even for reasonable desktop and server use locks are better.
2 replies 0 retweets 0 likes -
But I don't think this is solvable in Linux. The code using the RCU api actually does the alloc/free operations...
2 replies 0 retweets 0 likes -
Replying to @RichFelker @jfbastien
Any chance of a clear statement of what you believe the problem to be? :-)
1 reply 0 retweets 0 likes -
Replying to @paulmckrcu @jfbastien
Aside from overall complexity cost, the fact that RCU users have to alloc/free data that otherwise would be perm.
2 replies 0 retweets 0 likes
This makes it near-impossible to guard against catastrophic failure on OOM (needs difficult & costly accounting).
-
-
Replying to @RichFelker @jfbastien
The stall warning you encountered is part of that accounting.
1 reply 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.