Note: you don't have 12 point font. This isn't a big deal but it is also not particularly fair to other people who actually read the submission guidelines. An excellent paper. I can find no major faults. You cover the subject matter in an organized, thorough fashion. If I had to make one suggestion: you might have included more discussion of the application characteristics that lend themselves to one scheme more than another. Actually, I think you did a very good job but perhaps a few more examples (maybe in the conclusion) would have tied everything together in a more interesting way. Also, a brief explanation of the algorithm given by Amza would have been appropriate. In any case, as I stated before, I think that this is an excellent paper. ====================================================================== The paper was full of detailed information and seemed well organized to present it. The section headers made it easy to skim for an overview and find information later. The paper was often difficult to read - primarily from an English grammar standpoint. It also suffered from too many hands! :) On the one hand X, on the other hand Y, but Z on the other hand... Don't feel the need to use filler words to make sentence transitions. Use "active" sentences. Keep the sentences tight, limited to the facts (or evaluation of the facts). Introduce concepts before referencing them. The "ping-pong" problem was addressed and then described. Reorder and claim one problem caused by XXX in the need for multiple processors to YYY. This is known as the ping-pong problem and is addressed by ZZZ. Pg 7, load balancing can have adverse (vice adversary) effects. In the conclusion, I was confused by "performance reducing software." Also in the conclusion, it seems a weak argument to tell me to go get more powerful hardware to improve performance. I liked the use of the graphics, but they were a little terse with the abbreviations. The use of italicized phrases helped identify key points. I liked the structure and the level of detail. I thought each of the points was pretty well addressed. Nice job. ====================================================================== Good paper - even though some of the ideas discussed had already been talked about in class (release constency), the paper went further in depth and applied them to DSM systems. The balance of the paper seemed a little off - there was a good deal of information regarding consistency protocols, then much less information regarding page size and speculative coherancy. Yet these latter 2 topics were just as important in terms of overall software performance in DSM systems. The comparison sections were well done, as was the future directions. ====================================================================== This paper analyzes the design issues that affect the performance in software DSMs. The paper has a good flow. The points it made were clear and were backup with in depth analysis. However, I do find section 2.4 is a bit heavy, makes me sleepy. ====================================================================== Your paper is good on the whole. But here are a few points to note. While you claim that consistency models and page sizes are very important for Distributed systems, you don't talk much at all about page sizes -- it would have been a different matter if you had explicitly claimed that you did not intend to examine that aspect -- a survey should claim to examine something and succeed in their claims; it need not study everything! There are too many terms and acronyms in the paper, so after reading your section on consistency, one hardly remembers what you said, although you said it well! You should have had a table to provide a quick comparison of these consistency models. Your topic is on Performance, but you do not seem to have explicitly and clearly defined what "performance" means for this system -- so you must mention something about what numbers would make up good performance. And in the section on consistency models, you talk about the implementation aspects first and then talk about the concepts. Normally, one would expect to have the concepts explained first and then implementation, so that the motivation and context of the implementation becomes clear. The abstract should also say "what you have done in this paper", and not merely "what this area of research looks like". It is good to mention the organization of the paper in the introduction itself -- it clarifies sets the stage for everything else to come. Your paper is not in 12pt font -- and you do not make use of the available 10 pages -- strange! ====================================================================== This paper presents distributed shared memory (DSM). Although the implementation of DSM is limited by the current network latency, it will be considered in the near future. This paper is a good introduction about DSM and the problems DSM is trying to solve. It also keeps track of the possible solutions to these problems. It gives a clear picture of current research on DSM. I only feel confused about the integrated compiler mentioned in section 5. But I think the analysis of influence of load balancing on locality is really good.