From: Nathan Scott <nathans@sgi.com>
To: mingo@elte.hu, Daniel Walker <dwalker@mvista.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: RT and XFS
Date: Wed, 13 Jul 2005 10:25:56 +1000 [thread overview]
Message-ID: <20050713002556.GA980@frodo> (raw)
In-Reply-To: <1121209293.26644.8.camel@dhcp153.mvista.com>
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.
> --- linux.orig/fs/xfs/linux-2.6/mrlock.h
> +++ linux/fs/xfs/linux-2.6/mrlock.h
> @@ -37,12 +37,12 @@
> enum { MR_NONE, MR_ACCESS, MR_UPDATE };
>
> typedef struct {
> - struct rw_semaphore mr_lock;
> - int mr_writer;
> + struct compat_rw_semaphore mr_lock;
> + int mr_writer;
> } mrlock_t;
The XFS code is also written such that it just releases a mrlock
without tracking whether it had it for access/update in the end
(end lock state is not necessarily how it started out, since it
may have downgraded the lock at some point, or it may not have).
Its a non-trivial change to track that state within XFS itself,
so the above mr_writer field in XFS's mrlock wrapper tracks that
state alongside the rw_semaphore. It would prefer to be getting
that out of the rw_semaphore itself, alot, but there's not any
mechanism for doing so (its not a particularly nice API change
either, really, for the generic locking code). I guess that may
have been another reason for the above change in the RT patch, I
don't know all the details there.
cheers.
--
Nathan
next prev parent reply other threads:[~2005-07-13 0:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-12 23:01 RT and XFS Daniel Walker
2005-07-12 23:39 ` William Weston
2005-07-13 0:25 ` Nathan Scott [this message]
2005-07-13 0:41 ` Daniel Walker
2005-07-13 0:37 ` Nathan Scott
2005-07-13 6:47 ` Ingo Molnar
2005-07-13 16:45 ` Daniel Walker
2005-07-14 0:22 ` Nathan Scott
2005-07-14 3:50 ` Dave Chinner
2005-07-14 4:10 ` Daniel Walker
[not found] ` <20050714052347.GA18813@elte.hu>
2005-07-14 15:56 ` Daniel Walker
2005-07-14 16:08 ` Christoph Hellwig
2005-07-18 12:10 ` Esben Nielsen
2005-07-19 3:26 ` Bill Huey
2005-07-19 12:34 ` Ingo Molnar
2005-07-19 13:27 ` Christoph Hellwig
2005-07-19 13:50 ` Ingo Molnar
2005-07-14 16:08 ` Christoph Hellwig
2005-07-15 10:23 ` Ingo Molnar
2005-07-15 16:16 ` Daniel Walker
2005-07-18 11:33 ` Esben Nielsen
2005-07-19 3:31 ` Bill Huey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050713002556.GA980@frodo \
--to=nathans@sgi.com \
--cc=dwalker@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.