------------------------------------------------------------------------------ The observations were good, although, they were most of them are quit obvious. For process migration (section 6), In my opinion we have to avoid process migration as possible as we can, especially for the heterogeneous systems. A good scheduling algorithm will make process migration needless...! ------------------------------------------------------------------------------ I really liked the logical division of this paper into short-term scheduling, long-term scheduling, loop scheduling, and process migration. There was an inherent choppiness to the paper however. Several of the sections looked as though they had been cut off and could have used summarizing/concluding paragraphs. Also, the conclusion felt cut short as well. They integrated their own commentary into the paper very well. I liked the discussion of future trends and it's consideration of future architecture, however there were few suggestions for improvements. While the topics surveyed were adequate, a little more research into short-term scheduling might have provided a little more balance to the paper. I also liked the development of scheduling techniques by listing problems, and giving the mechanisms surveyed as solutions to problems. The division of the problems into Good Processor Utilization, Synchronization Effectiveness, and low communication/memory-access cost was also helpful. The discussion of system architectures was really good too. However, all of these introductory sections were not referenced enough in the rest of the paper (i.e. to show how certain systems helped various problems). This paper feels as though it could have been incredibly excellent (i.e. overall 7) if just a little more time was spent on it. However, as it is it still has some rough edges, and synthesization issues with definitions, statements, etc. ------------------------------------------------------------------------------ Footnote 1 is not referred in context, and seems not strongly related to reference 5. There are two footnotes numbered as 1. Why do the authors decompose the scheduling into three levels? If the idea is new, more reasoning and explanation will make readers feel comfortable to accept it. The relation between three levels is not covered in the paper. The choice of approach for one level will affect the complexity and performance of the other levels. Section 6 task migration is actually one of the factors for the long term scheduling proposed in the section 4. There is not enough evidence support to put them as an individual section. Typos: section 1, paragraph 2, line4, "describe" section 8, most important paragraph, line 6, "assigns" ------------------------------------------------------------------------------ I found it a nice introduction into multi-processor scheduling. The decomposition into 3 levels of scheduling is a good intellectual framework that makes the task more tractable. Section 1.1 could be titled "The Three Scheduling Goals". It would be nice to have these goals reappear in the Conclusion. They occasionally reappear in the analysis of the different scheduling techniques. I think this could be used to tie the paper together more cohesively. For example, 5.1 could explicitly state that this technique addresses the goals of utilization and effectiveness. It seems that the goal of long term scheduling is to ensure that communicating tasks are able to have multiple communications per schedule quantum with the other members of their task group. The goal in short-term scheduling is less clear. Are spin blocks the only technique? How do I choose between static and dynamic approaches for loop and long-term scheduling? The task migration topic appears out of the blue. Is this a long term scheduling technique or a loop scheduling technique? Is it something different? The discussion of system architectures and memory models (UMA, NOW, NUMA) is interesting, but is never again used in the paper. Section 4.1.1 is presumably about UMA architectures? How does NOW and NUMA effect Multiprocessor scheduling, at any level. Task migration: Why does a widely varying workload foil self guided migration strategies? What are typical problems that must be avoided? Another migration strategy is used by Kea. They signal the process to migrate and it then builds a migration packet and halts. It's then fairly easy to move the process state and continue on another address space. ------------------------------------------------------------------------------ The paper is well written and organized. The authors could have covered a wider range of task migration methodologies. Nevetheless, a good overview of the general multiprocessor scheduling problem is presented.