Messages in this thread | | | Date | Fri, 20 Feb 2015 10:11:07 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH tip/core/rcu 0/4] Programmatic nestable expedited grace periods |
| |
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.
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?
| |