Dmitry Torokhov a écrit :> On Thursday 19 March 2009 20:20:32 Arjan van de Ven wrote:>>> I don't claim to understand the code in question, so it is entirely>>> possible that the following is irrelevant. But one other reason for>>> synchronize_rcu() is:>>>>>> 1. Make change.>>>>>> 2. synchronize_rcu()>>>>>> 3. Now you are guaranteed that all CPUs/tasks/whatever>>> currently running either are not messing with you on the one hand, or>>> have seen the change on the other.>> ok so this is for the case where someone is already iterating the list.>>>> I don't see anything in the code that assumes this..> > This is something that input core guarantees to its users: by the time> input core calls hander->start() or, in its absence, by the time> input_register_handle() returns, events from input drivers will be> passed into the handle being registered, i.e. the presence of the> new item in the list is noticed by all CPUs.> > Now, it is possible to stop using RCU primitives in the input core> but I think that you'd want to figure out why synchronize_rcu()> takes so long first, otheriwse you may find another "abuser"> down the road.>

If a cpu does a loop, it nearly impossible that synchronize_rcu() canbe fast.

We had same problem in ksoftirqd(), where I had to add a callto rcu_qsctr_inc() to unblock other threads blocked in synchronize_rcu()