Re: Question about usage of RCU in the input layer

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Sat, Mar 21, 2009 at 10:13:38AM +0100, Eric Dumazet wrote:
> 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() can
> be fast.
> 
> We had same problem in ksoftirqd(), where I had to add a call
> to rcu_qsctr_inc() to unblock other threads blocked in synchronize_rcu()
> 
> http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=64ca5ab913f1594ef316556e65f5eae63ff50cee
> 
> If a driver does a loop with no call to scheduler, it might have same problem

And hopefully Arjan's promised bootgraph will give us some insights
as to what might be holding up the grace period.

							Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html