: Do we here have systems with that high a load average from actual use? No
:
: Point is, it's possible, and it's becoming more and more probable every day.
So the answer is "no, we have no data that supports our claims but we think
we are right anyway".
OK, I'll see your theory and raise you lots of actual practice. All of
the systems which support the sort of scheduling you want have piss poor
uniprocessor performance. There is a direct correlation between that
thinking on high end performance and the piss poor low end performance.
If it were my call, the statement I would make is this:
every line of code, every cache miss, every resource you use for
large machines which penalizes low end machines, is allowed only
in the same proportions of large machine seats vs low end machine
seats.
In other words, big servers do represent a market, but a very little market.
So sure, you get to change the kernel around. But only as much as your
market represents.
And stuff like "it only hurts 1%" is exactly how you get to garbage.
1% is huge. 1% is totally unacceptable. 1 cache line miss in a
critical path is unacceptable.
This is the fundementally ignored point in all of the Unix vendors
and now that they have f*cked up their operating systems, they want to
junp on the Linux bandwagon and do the same thing here. It makes me
livid with rage that these people have learned nothing from their past
mistakes and I wish they would stop and consider that maybe Linux isn't
the right place to repeat these mistakes.
I have a 9 month old son. Just maybe he will grow up and want to hack on
operating systems (probably not, but maybe). I'd really like it if Linux
was still a fun, small, fast system that people would enjoy. It sure
as hell won't survive 30 years of so called performance enhancements,
now will it?
I suspect you'll hear a dead silence from perf guys. Or claims of "no
OS lasts that long". Well, it's my position that Linux will last that
long and I want it to be something my feeble mind can grasp when I'm 65.
A bunch of narrowly focussed performance hacks will make that impossible.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:24 EST