[ Good, looks more like it ]
Now, the problem with dbench is that no way in hell should you optimize
for dbench in general, because it is a sucky kind of benchmark.
For example, waiting until the last possible minute for writeouts is
definitely the best setting for dbench, but it's a pretty horrible setting
for usability.
I suspect that for optimal dbench performance we'll always have to let teh
system admin do the above kind of horrible tweaking stuff, but at the same
time I personally absolutely detest the need for tweaks in general, and I
would like the default behaviour to be reasonable.
Killing kupdated, for example, is not really "reasonable". But I also
suspect that now that dirty balancing works sanely, the "start writeout at
30% full" is a bit early too.
So instead of the 30/60% split (the first number is "when do we start
writing things out", and the second number is "when do we start actively
waiting for it"), a 50/75% setup might be more reasonable for regular
loads, while making dbench at least a bit happier.
Are you (or others) willing to play around with the numbers a bit and look
at both dbench performance and at interactive feel?
In general
echo x 64 64 256 500 3000 y > /proc/sys/vm/bdflush
will set the "start writeout" to 'x'%, and the "start synchronous wait" to
'y'% (and restart kupdated with "killall -CONT kupdated"). It would be
interesting to hear where the sweet spot is.
Linus
-
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/