Re: RT and XFS

[Nathan Scott <nathans@sgi.com>]

Hi there,

On Wed, Jul 13, 2005 at 09:45:58AM -0700, Daniel Walker wrote:
> On Wed, 2005-07-13 at 08:47 +0200, Ingo Molnar wrote:
> > 
> > downgrade_write() wasnt the main problem - the main problem was that for 
> > PREEMPT_RT i implemented 'strict' semaphores, which are not identical to 
> > vanilla kernel semaphores. The thing that seemed to impact XFS the most 
> > is the 'acquirer thread has to release the lock' rule of strict 
> > semaphores.  Both the XFS logging code and the XFS IO completion code 
> > seems to release locks in a different context from where the acquire 
> > happened. It's of course valid upstream behavior, but without these 
> > extra rules it's hard to do sane priority inheritance. (who do you boost 
> > if you dont really know who 'owns' the lock?) It might make sense to 
> > introduce some sort of sem_pass_to(new_owner) interface? For now i 
> > introduced a compat type, which lets those semaphores fall back to the 
> > vanilla implementation.

Hmm, I'm not aware of anywhere in XFS where we do that.  From talking
to some colleagues here, they're claiming that we can't be doing that
since it'd trip an assert in the IRIX mrlock code.

> There's a lot of code like this in there .. I've seen some that down()
> in process contex, and up() in interrupt contex which is weird .. But
> those aren't major features, just little drivers. XFS is pretty major
> feature.
> 
> Nathan, does XFS need this property or could we convert it to
> synchronize the locking (with ease?)?

I'm not yet sure in what situations we are doing this, so can't
really say.  It'd be interesting to see an implementation of the
downgrade_write functionality and then a specific case where the
above locking behaviour happens ... and I'd then be able to say
how tricky that would be to resolve.

Steve, are you aware of situations where we unlock in a different 
thread to where we acquired the lock?  It'd surprise me, as we're
holding these things for as short a time as possible - afaict the
transactions always ilock, copy delta to iclog, pin, and unlock,
no?  (all in the same thread).  I can't see the iolock being used
in this way anywhere either... you?

cheers.

-- 
Nathan