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

[Andrew Morton]

Ingo Molnar <mingo@xxxxxxx> wrote:
>
> 
> * Andrew Morton <akpm@xxxxxxxx> 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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/