Re: [patch 0/9] mutex subsystem, -V4

[Andrew Morton <akpm@osdl.org>]

Ingo Molnar <mingo@elte.hu> wrote:
>
> 
> * Andrew Morton <akpm@osdl.org> wrote:
> 
> > > hm, can you see any easy way for me to test my bold assertion on ext3, 
> > > by somehow moving/hacking it back to semaphores?
> > 
> > Not really.  The problem was most apparent after the lock_kernel() 
> > removal patches.  The first thing a CPU hit when it entered the fs was 
> > previously lock_kernel().  That became lock_super() and performance 
> > went down the tubes.  From memory, the bad kernel was tip-of-tree as 
> > of Memorial Weekend 2003 ;)
> > 
> > I guess you could re-add all the lock_super()s as per 2.5.x's 
> > ext3/jbd, check that it sucks running SDET on 8-way then implement the 
> > lock_super()s via a mutex.
> 
> ok - does the patch below look roughly ok as a really bad (but 
> functional) hack to restore that old behavior, for ext2?
> 

Hard to tell ;) 2.5.20's ext2 had 7 lock_super()s whereas for some reason
this patch adds 12...

I don't recall whether ext2 suffered wild context switches as badly as ext3
did.  It becomes pretty obvious in testing.

The really bad workload was SDET, which isn't available to mortals.  So
some hunting might be neded to find a suitable alternative.  dbench would be
a good start I guess.

-
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/