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. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
