* Nathan Scott <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 12, 2005 at 04:01:32PM -0700, Daniel Walker wrote:
> >
> > Is there something so odd about the XFS locking, that it can't use the
> > rt_lock ?
>
> Not that I know of - XFS does use the downgrade_write interface, whose
> use isn't overly common in the rest of the kernel... maybe that has
> caused some confusion, dunno.
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.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
