Messages in this thread | | | Subject | Re: Help in DSM design | Date | Sat, 04 Mar 2000 01:39:21 -0800 | From | Larry McVoy <> |
| |
: > 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/
| |