Re: [tbench regression fixes]: digging out smelly deadmen.

[Mike Galbraith <efault@gmx.de>]

On Mon, 2008-10-27 at 14:42 +0100, Jiri Kosina wrote:
> On Mon, 27 Oct 2008, Mike Galbraith wrote:
> 
> > > real world workloads. If your fairness hurts throughput that much maybe
> > > your scheduler algorithm is just plain *wrong* as it isn't adapting to
> > > workload at all well.
> > Doesn't seem to be scheduler/fairness.  2.6.22.19 is O(1), and falls
> > apart too, I posted the numbers and full dbench output yesterday.
> 
> We'll need to look into this a little bit more I think. I have sent out 
> some numbers too, and these indicate very clearly that there is more than 
> 50% performance drop (measured by dbench) just after the very merge of CFS 
> in 2.6.23-rc1 merge window.

Sure.  Watching the per/sec output, every kernel I have sucks at high
client count dbench, it's just a matter of how badly, and how long.

BTW, the nice pretty 160 client numbers I posted yesterday for ext2
turned out to be because somebody adds _netdev mount option when I mount
-a in order to mount my freshly hotplugged external drive (why?  that
ain't in my fstab).  Without that switch, ext2 output is roughly as
raggedy as ext3, and nowhere near the up to 1.4GB/sec I can get with
dirty_ratio=50 + ext2 + (buy none, get one free) _netdev option.  Free
for the not asking option does nada for ext3.

	-Mike