Paul E. McKenney
Posts
87Following
50Followers
200
Paul E. McKenney
paulmckrcu
@rpsu Check the law carefully. The daylight-saving-time proponents on West Coast USA stopped an initiative some years back by redirecting from permanent standard time to permanent daylight-savings time. Most people (myself included) didn't care which time, as long as time didn't change.
Except that USA Federal law allows any state to unilaterally revert back to standard time, but an act of USA Congress is requited for a state to move to permanent daylight-savings time. Which meant that the resulting state laws had no effect.
Clever, these hobbits... :-/
Except that USA Federal law allows any state to unilaterally revert back to standard time, but an act of USA Congress is requited for a state to move to permanent daylight-savings time. Which meant that the resulting state laws had no effect.
Clever, these hobbits... :-/
0
0
2
Paul E. McKenney
paulmckrcu
1
0
1
Paul E. McKenney
paulmckrcu
@tobinbaker Let's just say that I have been working with C compilers for more than forty years, and have noticed certain trends. ;-)
0
0
2
Paul E. McKenney
paulmckrcu
@tobinbaker If it makes you feel better, Linux-kernel RCU uses a similar optimization in its callback lists. We are actually looking towads a combined scheme where we use the global ->gp_seq, but only for groups of callbacks.
On the other hand, the polled APIs, poll_state_synchronize_rcu() and friends, access the global information. If these become heavily used, this might need to change. Though commodity systems are continuing to become more tightly integrated with increasing fractions of hardware going to GPGPUs, so who knows?
On the other hand, the polled APIs, poll_state_synchronize_rcu() and friends, access the global information. If these become heavily used, this might need to change. Though commodity systems are continuing to become more tightly integrated with increasing fractions of hardware going to GPGPUs, so who knows?
0
0
1
Paul E. McKenney
paulmckrcu
@tobinbaker Careful of lifetime-end pointer zap! Treiber wrote in assembly language, thus no zap worries. Working to fix this issue: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2414r10.pdf
1
0
1
Paul E. McKenney
paulmckrcu
@tobinbaker @pkhuong @jwseigh Sounds good, then! And for its part, Linux-kernel (ab)uses the lock dependency checker (lockdep) to detect blocking within RCU readers.
Circling back to Joe Seigh's post, RCU (including EBR) is a specialized tool, so it does have limits. Part of the problem is that we do not yet have a complete concurrency toolkit (and maybe never will), so concurrency tools will continue to get put to jobs for which they are not well suited, RCU included. C'est la vie!
Circling back to Joe Seigh's post, RCU (including EBR) is a specialized tool, so it does have limits. Part of the problem is that we do not yet have a complete concurrency toolkit (and maybe never will), so concurrency tools will continue to get put to jobs for which they are not well suited, RCU included. C'est la vie!
0
0
1
Paul E. McKenney
paulmckrcu
@tobinbaker @pkhuong @jwseigh OK, that does make a lot of sense!
Do you also have the update side flag the offending thread when a grace period extends for too long? (AKA thread keeping epoch open for too long.)
Do you also have the update side flag the offending thread when a grace period extends for too long? (AKA thread keeping epoch open for too long.)
1
0
0
Paul E. McKenney
paulmckrcu
@tobinbaker @pkhuong @jwseigh OK, I will bite... Why do you need them "everywhere" instead of only on the update side?
1
0
0
Paul E. McKenney
paulmckrcu
@jwseigh @tobinbaker @pkhuong One way of looking at RCU (of which EBR is a set of implementations) is as a replacement for reader-writer locking. Staying in an RCU reader for too long is just as bad as staying in a reader-writer-locking reader for too long. In the Linux kernel, we use stall warnings to catch these usage bugs, but user-mode implementations seem slow to adopt this approach.
1
0
1
Paul E. McKenney
paulmckrcu
@ptesarik @clankgy1 @kernellogger Looking forward to it! But why wait? Valentine's day is on February 14th over here, and what better day for a heart of spaces? ;-)
0
0
2
Paul E. McKenney
paulmckrcu
@clankgy1 @kernellogger What Marcus Müller said! Perhaps the "fmt" command needs help in this regard? Or perhaps the "fmt" developers decided to have a bit of fun. ;-)
0
0
1
Paul E. McKenney
paulmckrcu
@keithp Then Linux-kernel tools/include/nolibc will provide you with even more irritation!!! ;-)
1
0
0
Paul E. McKenney
paulmckrcu
@kunev Agreed, but are they more stupid or less stupid than human beings?
0
0
0
Paul E. McKenney
paulmckrcu
@ljs Yes, it is necessary to make conscious and careful tradeoffs. Necessary, but not necessarily popular. Sound bites are much more fun, after all! ;-)
0
0
2
Paul E. McKenney
paulmckrcu
@ljs In some cases, short term vs. long term viewpoint. Given a reasonably stable environment, long term normally wins.
But if, and only if, you survive the short term. ;-)
But if, and only if, you survive the short term. ;-)
1
0
3
Paul E. McKenney
paulmckrcu
@geert Glad you like it! I am now working on some changes to better handle more corner cases.
0
0
2
Paul E. McKenney
paulmckrcu
@dvim I don't see any marking, but to be fair, given that it does involve Duplos and Legos, "for kids" might not be entirely inappropriate. ;-)
0
0
0
Paul E. McKenney
paulmckrcu
And my Kernel Recipes talk is now available: https://youtu.be/qYPCL1KGdQA
A big "Thank you!" to everyone involved!
A big "Thank you!" to everyone involved!
1
10
18