[lkml]   [2009]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Question about usage of RCU in the input layer
On Thu, Mar 19, 2009 at 07:18:41AM -0700, Arjan van de Ven wrote:
> On Thu, 19 Mar 2009 14:26:28 +0530
> Dipankar Sarma <> wrote:
> > On Wed, Mar 18, 2009 at 09:58:12PM -0700, Arjan van de Ven wrote:
> > > Hi,
> > >
> > > the input layer does a "synchronize_rcu()" after a
> > > list_add_tail_rcu(), which is costing me 1 second of boot time.....
> > > And based on my understanding of the RCU concept, you only need to
> > > synchronize on delete, not on addition... so I think the
> > > synchronize is entirely redundant here...
> >
> > The more appropriate question is - why is synchronize_rcu() taking
> > 1 second ? Any idea what the other CPUs are doing at the time
> > of calling synchronize_rcu() ?
> one cpu is doing a lot of i2c traffic which is a bunch of udelay()s
> in loops.. then it does quite a bit of uncached memory access, and
> the lot takes quite while.
> > What driver is this ? How early
> > in the boot is this happening ?
> during kernel boot.
> I suppose my question is also more generic.. why synchronize when it's
> not needed? At least based on my understanding of RCU (but you're the
> expert), you don't need to synchronize for an add, only between a
> delete and a (k)free.....

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.

It sounds like you are seeing these delays later in boot, however,
if this this is instead happening before the scheduler is operational,
please check to make sure that the following patch is applied:

This patch will also -greatly- improve performance on single-CPU systems,
as in the patch makes synchronize_rcu() be essentially a no-op in the
single-CPU case for Classic RCU.

Alternatively, again assuming a single-CPU system, the following patch
also effectively makes synchronize_rcu() be a no-op while also cutting
down the kernel's memory footprint:

Thanx, Paul

 \ /
  Last update: 2009-03-20 03:11    [W:0.044 / U:56.620 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site