passed through dynticks

Posted Apr 24, 2008 19:27 UTC (Thu) by ds2horner (subscriber, #13438)
In reply to: Integrating and Validating dynticks and Preemptable RCU by ds2horner
Parent article: Integrating and Validating dynticks and Preemptable RCU

mightn't 

(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 (✭ supporter ✭, #9624) [Link] (3 responses)

Excellent points, all on the money!!!  I clearly should submit more of my code to LWN for
review!!!

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!

passed through dynticks

Posted Apr 26, 2008 3:12 UTC (Sat) by ds2horner (subscriber, #13438) [Link] (2 responses)

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
concepts.

I would like to suggest a further code simplification in rcu_try_flip_waitmb_needed.

  if ((curr == snap) && ((curr & 0x1) == 0))
    return 0;
  if (curr != snap)
    return 0;

reduces to:

if ((curr & 0x1) == 0 || (curr != snap) )
    return 0;

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.
should be 

while lines 5 and 6 ... (not 4 and 5)  
and
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
recommendations.

passed through dynticks

Posted Apr 27, 2008 0:13 UTC (Sun) by PaulMcKenney (✭ supporter ✭, #9624) [Link] (1 responses)

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
email.

RCU reviews

Posted Apr 27, 2008 4:03 UTC (Sun) by ds2horner (subscriber, #13438) [Link]

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
rcu_try_flip_waitack_needed. 

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
benefit.

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
correspondence.

Thanks again for these informative (and thought provoking) articles.