Messages in this thread | | | Date | Mon, 1 Sep 2014 09:05:50 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH RFC tip/core/rcu] Eliminate deadlock between CPU hotplug and expedited grace periods |
| |
On Mon, Sep 01, 2014 at 01:20:59PM +0200, Peter Zijlstra wrote: > On Thu, Aug 28, 2014 at 12:47:45PM -0700, Paul E. McKenney wrote: > > Currently, the expedited grace-period primitives do get_online_cpus(). > > This greatly simplifies their implementation, but means that calls to > > them holding locks that are acquired by CPU-hotplug notifiers (to say > > nothing of calls to these primitives from CPU-hotplug notifiers) can > > deadlock. But this is starting to become inconvenient: > > https://lkml.org/lkml/2014/8/5/754 > > Please recap the actual problem; the link might die and the actual mail > linked to isn't very useful in any case.
Will do.
> > This commit avoids the deadlock and retains the simplicity by creating > > a try_get_online_cpus(), which returns false if the get_online_cpus() > > reference count could not immediately be incremented. If a call to > > try_get_online_cpus() returns true, the expedited primitives operate > > as before. If a call returns false, the expedited primitives fall back > > to normal grace-period operations. This falling back of course results > > in increased grace-period latency, but only during times when CPU > > hotplug operations are actually in flight. The effect should therefore > > be negligible during normal operation. > > URGH.. I really hate that. The hotplug interface is already too > horrible, we should not add such hacks to it.
We do have try_ interfaces to a number of other subsystems, so I don't believe that it qualifies as such a hack.
> How about ripping that rcu_expedited stuff out instead? That's all > conditional anyhow, so might as well not do it.
In what way is the expedited stuff conditional?
Thanx, Paul
| |