Messages in this thread | | | Date | Wed, 2 Oct 2013 10:52:13 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH] hotplug: Optimize {get,put}_online_cpus() |
| |
On Wed, Oct 02, 2013 at 04:00:20PM +0200, Oleg Nesterov wrote: > On 10/02, Peter Zijlstra wrote: > > > > On Wed, Oct 02, 2013 at 02:13:56PM +0200, Oleg Nesterov wrote: > > > In short: unless a gp elapses between _exit() and _enter(), the next > > > _enter() does nothing and avoids synchronize_sched(). > > > > That does however make the entire scheme entirely writer biased; > > Well, this makes the scheme "a bit more" writer biased, but this is > exactly what we want in this case. > > We do not block the readers after xxx_exit() entirely, but we do want > to keep them in SLOW state and avoid the costly SLOW -> FAST -> SLOW > transitions.
Yes -- should help -a- -lot- for bulk write-side operations, such as onlining all CPUs at boot time. ;-)
Thanx, Paul
> Lets even forget about disable_nonboot_cpus(), lets consider > percpu_rwsem-like logic "in general". > > Yes, it is heavily optimizied for readers. But if the writers come in > a batch, or the same writer does down_write + up_write twice or more, > I think state == FAST is pointless in between (if we can avoid it). > This is the rare case (the writers should be rare), but if it happens > it makes sense to optimize the writers too. And again, even > > for (;;) { > percpu_down_write(); > percpu_up_write(); > } > > should not completely block the readers. > > IOW. "turn sync_sched() into call_rcu_sched() in up_write()" is obviously > a win. If the next down_write/xxx_enter "knows" that the readers are > still in SLOW mode because gp was not completed yet, why should we > add the artificial delay? > > As for disable_nonboot_cpus(). You are going to move cpu_hotplug_begin() > outside of the loop, this is the same thing. > > Oleg. >
| |