Re: [ANNOUNCE] 3.2.9-rt17

On Thu, 2012-03-08 at 17:13 -0500, Steven Rostedt wrote:

quoted

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.