First of all, you're right.
Larry McVoy wrote:
> : 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".
>
Whatever. Obviously this thread is diving quickly into everyone yelling and no
one listening. Let's pull it back to where we need to be.
>
> 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.
>
What kind of scheduling I want? I just want an algorithm that doesn't fall apart
completely when the system is very heavily loaded. And right now, we linearly
walk the runqueue under a spinlock and re-calculate the goodness of everything on
it every time we call schedule(). While it's not bad on a small system, it's
horrible on a larger one. I just want something that works well on both my
workstation and the large servers I work on. Or at the very least, the ability to
switch between them, be it at runtime or compile time. Or someone to show me just
how wrong I am. :)
>
> 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.
>
Heh. You may not believe it, but that's a point of view I've been fighting for
around here for quite a while. It's just starting to get somewhere.
>
> 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.
>
I agree, those cache misses are probably going to be exacerbated on a large system
as well. I never fully understood the concept of "no worse than X% degradation
over previous" being considered acceptable.
>
> 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.
>
Gawd...I'm getting tired of agreeing with you already ;) I'm quite honestly busy
here trying to teach people building Tru64 some of the lessons that Linux
teaches. I'm very concerned that the SGIs and IBMs that are coming along (and, of
course, in some fashion the Compaqs) with all this pent up "experience" are only
going to screw Linux into the ground just like they have their own operating
systems.
The guarding factor is that there are people like Linus, Alan, David, yourself and
many others that will hopefully make sure only the right answers are used. And
hopefully everyone else will learn from the decisions made.
>
> 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?
>
Not if they are not done cleanly and clearly with an eye on the future. If we can
always be thinking of doing what's right, and not necessarily just what's easy or
obvious, I think Linux will be just fine.
>
> 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.
I am a "perf guy". And I don't want performance hacks. I think hacks just for
the sake of benchmarks are, well, disgusting. I want designs that aren't narrowly
focussed on any one application of an operating system, be it the person who just
installed Linux on his/her old PC at home or the company that just installed it on
their big new shiny server.
Larry, you mentioned that you had thoughts on what Linux has to do to work on big
servers. I'm imagining, given your background and the content of this email, that
they are also ideas that won't harm the performance on small systems (e.g.
desktops). I must have missed them somehow - could you recap? If people like the
ideas, I'll do everything to help. Maybe Compaq will to.... :) (Of course, I
can't speak for anyone but myself, now can I? ;)
- Pete
-
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:25 EST