Re: [patch 0/3] j_state_lock, j_list_lock, remove-bitlocks

Andrew Morton
2005-03-16T10:41:33Z

Ingo Molnar <mingo@elte.hu> wrote:
>
>
> * Andrew Morton <akpm@osdl.org> wrote:
>
> > > > There's a little lock ranking diagram in jbd.h which tells us that
> > > > these locks nest inside j_list_lock and j_state_lock. So I guess
> > > > you'll need to turn those into semaphores.
> > >
> > > indeed. I did this (see the three followup patches, against BK-curr),
> > > and it builds/boots/works just fine on an ext3 box. Do we want to try
> > > this in -mm?
> >
> > ooh, I'd rather not. I spent an intense three days removing all the
> > sleeping locks from ext3 (and three months debugging the result).
> > Ended up gaining 1000% on 16-way.
> >
> > Putting them back in will really hurt the SMP performance.
>
> seems like turning the bitlocks into spinlocks is the best option then.
> We'd need one lock in buffer_head (j_state_lock, renamed to something
> more sensible like b_private_lock), and one lock in journal_head
> (j_list_lock) i guess.

Those two are in the journal, actually. You refer to jbd_lock_bh_state()
and jbd_lock_bh_journal_head(). I think they both need to be in the
buffer_head. jbd_lock_bh_journal_head() can probably go away (just use
caller's jbd_lock_bh_state()).

Or make them global, or put them in the journal.

> How much would the +4/+8 bytes size increase in
> buffer_head [on SMP] be frowned upon?

It wouldn't be the end of the world. I'm not clear on what bits of the
rt-super-low-latency stuff is intended for mainline though?