On Sun, Feb 23, 2003 at 11:39:34PM -0800, Martin J. Bligh wrote:
> > The point being that there is a company generating $32B/year in sales and
> > almost all of that is in uniprocessors. Directly countering your
> > statement that there is no margin in PC's. They are making $2B/year in
> > profits, QED.
>
> Which is totally irrelevant. It's the *LINUX* market that matters. What
> part of that do you find so hard to understand?
OK, so you can't handle the reality that the server market overall doesn't
make your point so you retreat to the Linux market. OK, fine. All the
data anyone has ever seen has Linux running on *smaller* servers, not
larger. Show me all the cases where people replaced 4 CPU NT boxes with
8 CPU Linux boxes.
The point being that if in the overall market place, big iron isn't
dominating, you have one hell of a tough time making the case that the
Linux market place is somehow profoundly different and needs larger
boxes to do the same job.
In fact, the opposite is true. Linux squeezes substantially more
performance out of the same hardware than the commercial OS offerings,
NT or Unix. So where is the market force which says "oh, switching to
Linux? Better get more CPUs".
> It makes IBM money, ergo they pay me. I enjoy doing it, ergo I work for
> them. Most of the work benefits smaller systems as well, ergo we get our
> patches accepted. So everyone's happy, apart from you, who keeps whining.
Indeed I do, I'm good at it. You're about to find out how good. It's
quite effective to simply focus attention on a problem area. Here's
my promise to you: there will be a ton of attention focussed on the
scaling patches until you and anyone else doing them starts showing
up with cache miss counters as part of the submission process.
> So now we've slid from talking about bus traffic from fine-grained locking,
> which is mostly just you whining in ignorance of the big picture, to cache
> effects, which are obviously important. Nice try at twisting the
> conversation. Again.
You need to take a deep breath and try and understand that the focus of
the conversation is Linux, not your ego or mine. Getting mad at me just
wastes energy, stay focussed on the real issue, Linux.
> > People care about performance, both scaling up and scaling down. A lot of
> > performance changes are measured poorly, in a way that makes the changes
> > look good but doesn't expose the hidden costs of the change. What I'm
> > saying is that those sorts of measurements screwed over performance in
> > the past, why are you trying to repeat old mistakes?
>
> One way to measure those changes poorly would be to do what you were
> advocating earlier - look at one tiny metric of a microbenchmark, rather
> than the actual throughput of the machine. So pardon me if I take your
> concerns, and file them in the appropriate place.
You apparently missed the point where I have said (a bunch of times)
run the benchmarks you want and report before and after the patch
cache miss counters for the same runs. Microbenchmarks would be
a really bad way to do that, you really want to run a real application
because you need it fighting for the cache.
> > My argument is different because every effort which has gone in the
> > direction you are going has ended up with a kernel that worked well on
> > big boxes and sucked rocks on little boxes. And all of them started
> > with kernels which performed quite nicely on uniprocessors.
>
> So you're trying to say that fine-grained locking ruins uniprocessor
> performance now?
I've been saying that for almost 10 years, check the archives.
> You just don't get it, do you? Your head is so vastly inflated that you
> think everyone should run around researching whatever *you* happen to think
> is interesting. Do your own benchmarking if you think it's a problem.
That's exactly what I'll do if you don't learn how to do it yourself. I'm
astounded that any competent engineer wouldn't want to know the effects of
their changes, I think you actually do but are just too pissed right now
to see it.
> > Linux is a really fast system right now. [etc]
>
> Everyone. And we can do that, and make large systems work at the same time.
> Despite the fact you don't believe me. And despite the fact that you can't
> grasp the difference between the number 16 and the number 64.
See other postings on this one. All engineers in your position have said
"we're just trying to get to N cpus where N = ~2x where we are today and
it won't hurt uniprocessor performance". They *all* say that. And they
all end up with a slow uniprocessor OS. Unlike security and a number of
other invasive features, the SMP stuff can't be configed out or you end
up with an #ifdef-ed mess like IRIX.
-- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - 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/
This archive was generated by hypermail 2b29 : Fri Feb 28 2003 - 22:00:19 EST