On Mon, Apr 28, 2008 at 03:10:40PM +1000, David Chinner wrote:
quoted text
> On Fri, Apr 25, 2008 at 11:00:21AM -0600, Matthew Wilcox wrote:
> > 
> > It's been a Good Idea for a while to use mutexes instead of
> > semaphores where possible.  Additional debuggability, better optimised,
> > better-enforced semantics, etc.
> > 
> > Obviously, there are some places that can't be converted to mutexes.
> > I'm not proposing blind changes. 
> 
> Matthew, what's the plan for code using semaphores that cannot be
> easily converted to something else? e.g. XFS?

I'm glad you asked!

Arjan, Ingo and I have been batting around something called a kcounter.
I appear to have misplaced the patch right now, but the basic idea is
that it returns you a cookie when you down(), which you then have to
pass to the up()-equivalent.  This gives you at least some of the
assurances you get from mutexes.

Though ... looking at XFS, you have 5 counting semaphores currently:

1. i_flock

This one seems to be a mutex.  I'd need to immerse myself in XFS for a
couple of days to verify that though -- there's a lot of places that use
it, and it doesn't have obvious lock/unlock pairing.  Is it sometimes
unlocked from a different thread than the one which locked it?  If so,
kcounters might be the right thing to use here.

2. l_flushsema

This seems to be a completion.  ie you're using it to wait for the log
to be flushed.

3. q_flock

Ow.  ow.  My brain hurts.  What are these semantics?

4. b_iodonesema

This should be a completion.  It's used to wait for the io to be
complete.

5. b_sema

This looks like a mutex, but I think it's released in a different
context from the one which acquires it.

-----

Possibly XFS should be using constructs like wait_on_bit instead of
semaphores.  See the implementation of wait_on_buffer for an example.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/