On 06/11, Paul E. McKenney wrote: > > On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote: > > On 06/11, Paul E. McKenney wrote: > > > > > > I was thinking of ->boost_completion as the way to solve it easily, but > > > what did you have in mind? > > > > I meant, rcu_boost() could probably just do "mtx->owner = t", we know that > > it was unlocked by us and nobody else can use it until we set > > t->rcu_boost_mutex. > > My concern with this is that rcu_read_unlock_special() could hypothetically > get preempted (either by kernel or hypervisor), so that it might be a long > time until it makes its reference. But maybe that reference would be > harmless in this case.
Confused... Not sure I understand what did you mean, and certainly I do not understand how this connects to the proxy-locking method. Could you explain? > > And if we move it into rcu_node, then we can probably kill > > ->rcu_boost_mutex, > > rcu_read_unlock_special() could check rnp->boost_mutex->owner == current. > > If this was anywhere near a hot code path, I would be sorely tempted. Ah, but I didn't mean perfomance. I think it is always good to try to remove something from task_struct, it is huge. I do not mean sizeof() in the first place, the very fact that I can hardly understand the purpose of a half of its members makes me sad ;) Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
