One thing that I've often disliked about "tuning parameters" is that many
people take them to be valid excuses for bad behaviour under some load.
For example, when some benchmark does badly, or something stutters, you'll
always find somebody pointing out that it can be fixed by doing a

        echo 55 > /proc/sys/mm/dirty_ratio

or similar.  And the fact that you can tune the thing for certain loads
somehow thus makes the bug ok..

IT AIN'T SO! Tuning constants are wonderfully useful for developers tuning
their guesses a bit, and to give more information about what knobs make a
difference.

In other words, it's ok for a developer to say: "Ok, what happens if you
do the above echo?" to figure out whether maybe the problem is due to
excessive spurgel-production in the VM frobnicator, but it is NOT OK to
say "you can tweak it for your use, so don't complain about the bad
behaviour".

This is the same thing as "'nice -10' the X-server". Something is wrong,
and we couldn't fix it, so here's the band-aid to avoid that problem for
hat particular case. It's acceptable as a band-aid, but if you don't
realize that it's indicative of a problem, then you're just kidding
yourself.

Can we do perfectly all the time? No. Sometimes best performance _will_
require tuning for the load. But it should be seen as a failure of the
generic algorithm, not as a success.

Btw, "success" is often "being good enough". We shouldn't _suck_, but you
should always remember the old "perfect is the enemy of good" thing.
Trying to get perfect behaviour under some circumstances often means that
you suck under others, and then the right answer is usually not to try to
be so damn perfect, but "just being good".

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/