: > 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".
Really? Actually, I didn't pull it out of thin air - read any of the
many (rather pointless) PhD's on the topic, or do some benchmarks.
Or you could just _think_ before you _talk_. Remote page fault, best
case, around 2 milliseconds. Cache line miss, around 200ns. There's a
factor of 10,000 difference. Add in a really long think time and you
might be only a factor of ten slower, I was being very generous.
: > 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".
Been there, done that, several times over the last 10 years. What's
changed? It didn't work then, so what has changed?
: > 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.
No, you get a toy that looks neat for demos and works like shit in
practice. But please, don't take my word for it, step forward with
the list of programs that do work over DSM. Show me the numbers.
: > 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)
So you like a world were your cache line misses take 10,000
times longer than normal, do you? You know what, you're right.
If you have code that is so cache insensitive that it wouldn't
notice the difference, DSM would work great. I just have never
heard of a single example of code like that needs shared memory.
But if you have apps like that, more power to you. All I care
about it is that it never gets in the kernel. You shouldn't care
about if it is or it isn't, with latencies like that, you can
do your pager in user space and have the big fun.
-
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:16 EST