[email protected] wrote: > This is a case I was worried about from the instant you said that a multi > CPU task would take priority over N-1 single CPU tasks at the same > priority.
There's no obvious best policy. Suppose we have a 1-CPU job that's in deadline danger and an 8-CPU job that's not. Should we run the 1-CPU job? We'll have 7 idle CPUs. Should we run them both? We may kill the performance of the 8-CPU job. Should we run the 8-CPU job? The 1-CPU job might miss its deadline. (Currently we're taking the 3rd option). > The problem I had with the scheduler tester was that it was a major pain. > It took hours to generate a decent dataset that was not dominated by > startup interactions. It was also hard to generate scenarios that showed > the problems. Please note that when you insisted that all changes be > validated through the test suite that you stopped getting suggestions for > changes. The "seat of the pants" approach to scheduling policy design (implement it, have testers run it and describe the results anecdotally) is fine for the broad strokes, but as we move into the edge cases it becomes inadequate. With the simulator we can potentially test policy changes against a wide range of scenarios, and get the answers back in seconds. If the simulator is hard to use, we should make it easy to use, not throw it away. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
