linux-kernel - Re: Question about usage of RCU in the input layer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Mar 2009 19:07:50 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	dipankar@...ibm.com, linux-input@...r.kernel.org,
	dmitry.torokhov@...il.com, linux-kernel@...r.kernel.org
Subject: Re: 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 <dipankar@...ibm.com> 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:

	http://lkml.org/lkml/2009/2/25/558

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:

	http://lkml.org/lkml/2009/2/3/333

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