lkml.org 
[lkml]   [2000]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Help in DSM design

Larry McVoy writes:

> Anyway, the big problem with DSM is performance and the real problem is
> that there isn't a good answer. The DSM advocates all love to tell you
> about how it solves problems, porting is easier, computers are cheaper
> than people, etc. 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".

> So while the DSM crowd will tell you otherwise, there are definite,
> quantifiable limits about where it stops making sense.

No, the DSM crowd says "try it". I've seen the code, and I know that
you can port to DSM in a trivial amount of time. Most of your porting
problems need to be solved for message passing too, such as the
method used to start all your processes. The actual DSM changes can
be done with a perl script!

It is foolish to rewrite code that might run fast enough with a
quick DSM conversion. If DSM isn't right for your problem, then
you know to go ahead with the expensive rewrite.

> As far as I can tell, those limits are all in the performance area.
> If that's true, DSM is really only useful if it lives up to both the ease
> of use and the performance promise. Not only does it not, but it can't.

This is also just wrong. If there was a solution that was both
easier and faster than DSM, you might be right. You can only point
to solutions that are one or the other though. DSM is a compromise.
For both ease of use and the performance, you get something partway
between SMP and message passing.

> 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)


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.127 / U:0.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site