Messages in this thread |  | | Date | Fri, 10 Apr 2015 19:44:00 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] mutex: Speed up mutex_spin_on_owner() by not taking the RCU lock |
| |
* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > No RCU overhead, and this is the access to owner->on_cpu: > > > > 69: 49 8b 81 10 c0 ff ff mov -0x3ff0(%r9),%rax > > > > Totally untested and all that, I only built the mutex.o. > > > > What do you think? Am I missing anything? > > I suspect it is good, but let's take a look at Linus' summary of the code: > > rcu_read_lock(); > while (sem->owner == owner) { > if (!owner->on_cpu || need_resched()) > break; > cpu_relax_lowlatency(); > } > rcu_read_unlock();
Note that I patched the mutex case as a prototype, which is more commonly used than rwsem-xadd. But the rwsem case is similar as well.
> The cpu_relax_lowlatency() looks to have barrier() semantics, so the > sem->owner should get reloaded every time through the loop. This is > needed, because otherwise the task structure could get freed and > reallocated as something else that happened to have the field at the > ->on_cpu offset always zero, resulting in an infinite loop.
So at least with the get_kernel(..., &owner->on_cpu) approach, the get_kernel() copy has barrier semantics as well (it's in assembly), so it will be reloaded in every iteration in a natural fashion.
Thanks,
Ingo
|  |