Re: [ANNOUNCE] 3.2.9-rt17

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux