Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for June 20, 2013
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
(curr - snap) >= 2
be sufficient to determine if dynticks was entered and a sufficient condition
to exclude the cpu?
passed through dynticks
Posted Apr 26, 2008 1:05 UTC (Sat) by PaulMcKenney (subscriber, #9624)
Excellent points, all on the money!!! I clearly should submit more of my code to LWN for
I made the changes to spin, and all but the last (big) one completed
successfully. This last one is in progress, and will take a bit to complete. I will let you
know how it goes.
Thank you very much for your careful and productive review!
Posted Apr 26, 2008 3:12 UTC (Sat) by ds2horner (subscriber, #13438)
Thank you for your encouraging words.
I was reluctant to add more - ( still working through the logic and especially the Promela
modeling verification process) - until I got some confirmation that I was grasping the
I would like to suggest a further code simplification in rcu_try_flip_waitmb_needed.
if ((curr == snap) && ((curr & 0x1) == 0))
if (curr != snap)
if ((curr & 0x1) == 0 || (curr != snap) )
If we are in dynticks we have not done any RCU activity since entering (and have done the
required memory barrier on entry, so nothing to synch (is there a miniscule race here between
the setting of the dynticks_progress_counter and invoking of the barrier on the remote cpu?))
or we have transitioned dynticks states and therefore invoked the required mb.
And some more editting/profreading corrections:
like blank line 4 in rcu_irq_enter throwing off the description in the following paragraph.
while lines 5 and 6 ... (not 4 and 5)
Lines 7 and 8 .. (not 6 and 7)
Do you want me to report such text corrections?
I am still working my way through this.
I greatly appreciate such articles in LWN
- the description around the code greatly helps in validating possible corrections or
Posted Apr 27, 2008 0:13 UTC (Sun) by PaulMcKenney (subscriber, #9624)
Very good -- much simpler formulation! (A bit faster as well, but as this is the slow path,
the simplicity is more important.) Passes Promela/spin, and also rcutorture.
Feel free to post feedback, or email it to me if you prefer. Don't worry about line-number
mismatches, as they will all change anyway.
Would you be willing to review before publication on the next one? If so, please drop me an
Posted Apr 27, 2008 4:03 UTC (Sun) by ds2horner (subscriber, #13438)
I would be honoured to pre-view the next LWN article.
However, I believe I am mostly out of my league here.
I hope to not disappoint you.
I understand memory barriers are quite expensive (on most current machines that implement
them), so I have some suggestions for optimizations in rcu_try_flip_waitmb_needed and
And I understand mb is both read and write barrier. I plan on looking into the possibility of
using (the potentially) less expensive read (or write) barriers, if you think they may
I did not see your email anywhere on LWN - even in the new "GuestArticles index", so I will
look for your email on lkml. Having seen no other posts here, perhaps we are OK going private
Thanks again for these informative (and thought provoking) articles.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds