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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 20 Mar 2009 07:31:04 -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 Fri, Mar 20, 2009 at 06:50:58AM -0700, Arjan van de Ven wrote:
> On Thu, 19 Mar 2009 21:45:41 -0700
> "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
> 
> > > single CPU is soooo last decade ;-)
> > > But seriously I no longer have systems that aren't dual core or SMT
> > > in some form... 
> > 
> > OK, I will ask the stupid question...
> > 
> > Why not delay bringing up the non-boot CPUs until later in boot?
> 
> that'd be throwing out the baby with the bathwater... I'm trying to use 
> the other cpus to do some of the boot work (so that the total goes
> faster); not using the other cpus would be counter productive to that.
> (As is just sitting in synchronize_rcu() when the other cpu is
> working.. hence this discussion ;-)

OK, so you are definitely running multiple CPUs when the offending
synchronize_rcu() executes, then?

If so, here are some follow-on questions:

1.	How many synchronize_rcu() calls are you seeing on the
	critical boot path and what value of HZ are you running?

	If each synchronize_rcu() is taking (say) tens of jiffies, then,
	as Peter Zijlstra notes earlier in this thread, we need to focus
	on what is taking too long to get through its RCU read-side
	critical sections.  Otherwise, if each synchronize_rcu() is
	in the 3-5 jiffy range, I may finally be forced to create an
	expedited version of the synchronize_rcu() API.

2.	If expediting is required, then the code calling synchronize_rcu()
	might or might not have any idea whether or not expediting is
	appropriate.  If it does not, then we would need some sort of way
	to tell synchronize_rcu() that it should act more aggressively,
	perhaps /proc flag or kernel global variable indicating that
	boot is in progress.

	No, we do not want to make synchronize_rcu() aggressive all the
	time, as this would harm performance and energy efficiency in
	the normal runtime situation.

	So, if it turns out that synchronize_rcu()'s caller does not
	know whether or not expediting is appropriate, can the boot path
	manipulate such a flag or variable?

3.	Which RCU implementation are you using?  CONFIG_CLASSIC_RCU,
	CONFIG_TREE_RCU, or CONFIG_PREEMPT_RCU?

							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/