Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > * Andrew Morton <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
