Messages in this thread | | | Date | Fri, 20 Feb 2015 08:37:37 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH tip/core/rcu 0/4] Programmatic nestable expedited grace periods |
| |
On Fri, Feb 20, 2015 at 10:11:07AM +0100, Peter Zijlstra wrote: > On Thu, Feb 19, 2015 at 09:08:50PM -0800, Paul E. McKenney wrote: > > Hello! > > > > This series, possibly for v3.21, contains changes that allow in-kernel > > code to specify that all subsequent synchronous grace-period primitives > > (synchronize_rcu() and friends) be expedited. New rcu_expedite_gp() > > and rcu_unexpedite_gp() primitives enable and disable expediting, > > and these may be nested. Note that the rcu_expedited boot/sysfs > > variable, if non-zero, causes expediting to happen regardless of calls > > to rcu_expedite_gp(). > > > > Because one of the use cases for these primitives is to expedite > > grace periods during the in-kernel portion of boot, a new Kconfig > > parameter named CONFIG_RCU_EXPEDITE_BOOT causes the kernel to act > > as if rcu_expedite_gp() was called very early in boot. At the end > > of boot (presumably just before init is spawned), a call to > > rcu_end_inkernel_boot() will provide the matching rcu_unexpedite_gp() > > if required. > > So I though we wanted to get rid / limit the expedited stuff because its > IPI happy, and here its spreading.
Well, at least it no longer IPIs idle CPUs. ;-)
And this is during boot, when a few extra IPIs should not be a big deal.
> Does it really make a machine boot much faster? Why are people using > synchronous gp primitives if they care about speed? Should we not fix > that instead?
The report I heard was that it provided 10-15% faster boot times.
Thanx, Paul
| |