Hi,
On Sat, 4 Mar 2000 04:26:04 -0500 (EST), "Albert D. Cahalan"
<acahalan@cs.uml.edu> said:
>> But that's all nonsense if the model takes a 200 CPU system and
>> makes it perform like a 20 CPU SMP. Obviously, if that were the
>> case, people would just buy the SMP, it's cheaper and faster.
> DSM isn't nonsense. Porting _is_ easier and computers usually _are_
> cheaper than people. You pulled the "200" and "20" out of thin air;
> it is actually "249" and "243".
That turns out not to be the case. It was exactly this granularity
problem which killed the only machine I'm aware of which did DSM in
hardware (the Kendall Square boxes --- and how many people here have
heard of that one? :)
>> The problem is that this breaks the ease of use claim. You now have
>> to go through all your apps and teach them about the new memory model.
> Pages are like huge cache lines. Don't gripe about cache lines, OK?
> Good SMP code avoids cache line ping pong. Bad code doesn't bother.
> (then again, if the "bad" code was cheap, maybe it isn't so bad)
Have you _seen_ the effort people go to to avoid cache line effects on
SMP? In the 2.3 kernel right now, people are devoting *huge* amounts
of effort to dealing with this, it is so expensive. And that's just
flipping 32-byte cache lines over fast hardware buses. It's really
hard to deal with there, so how much more painful is the effect if
your granularity is the page and your bus runs over IP?
And if you say "well good DSM code can be aware of it and work around
the problems" then you've just eliminated the one advantage we agree
on about DSM --- that it is easy to program to.
--Stephen
-
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 : Tue Mar 07 2000 - 21:00:20 EST