Messages in this thread | | | Subject | Re: [ANNOUNCE] 3.2.9-rt17 | From | Peter Zijlstra <> | Date | Thu, 08 Mar 2012 23:20:13 +0100 |
| |
On Thu, 2012-03-08 at 17:13 -0500, Steven Rostedt wrote: > > task-A (cpu0) task-B (cpu1) task-C (cpu1) > > > > lock ->d_lock > > lock ->i_lock > > lock ->d_lock > > <-------------- preempts B > > trylock ->i_lock > > > > > > While is is perfectly normal, the result is that A stops spinning and > > goes to sleep. Now B continues and loops ad infinitum because it keeps > > getting ->d_lock before A because its cache hot on cpu1 and waking A > > takes a while etc.. > > I'm confused? As A isn't doing a loop. B is doing the loop because it's > trying to grab the locks in reverse order and can't take the i_lock. > Your example above would have A go to sleep when it tries to take > d_lock.
Right, but what guarantees that A will ever get ->d_lock when B releases it before B again acquires it?
B is in a very tight:
1: lock ->d_lock trylock ->i_lock unlock ->d_lock goto 1
loop, while A is doing:
1: trylock ->d_lock goto 1
and with rt-mutex having the equal priority lock stealing this reverts to a plain test-and-set lock. There's only a tiny window in which A can actually get the lock and that is hampered by B's cpu owning the cacheline in exclusive mode.
I simply cannot see guaranteed progress here.
| |