Yes, there is a tension between the goals as they are mutually conflicting.
Typically, a system has more jobs than just one N CPU job and 1 single CPU
job.
We need to review the order of priorities. I believe #1 is to not return
work work late. Use all resources is, I believe, a bit further down the
list.
I would propose that in the case that there are exactly two tasks, one an N
CPU task that is either not in deadline trouble, or has a later deadline
than the single CPU task that is in deadline trouble that we choose the
single CPU task that is in deadline trouble.
In addition, if there are any other Single CPU tasks or multi CPU tasks
that do not take every CPU on the system that those tasks be selected in
parallel to the single CPU system that is in deadline trouble. This has to
be done in the CPU scheduler, not in enforcement.
In addition, if there is a single CPU task that is in deadline trouble, and
the N CPU task is in deadline trouble, and the single CPU task has an
earlier deadline than the N CPU task, the single CPU task is selected, and
other single CPU tasks are then selected in EDF order. This has the effect
of minimizing the risk of other work being reported late.
In addition, if nothing is in deadline trouble, and there is a high LTD
single CPU task, then scheduling N single CPU tasks would be preferred to
scheduling a single low LTD N CPU task. Of course, in this case,
scheduling a single N CPU task would be preferred to scheduling N - 1
single CPU tasks. This is going to be a bit harder to manage than the EDF
scheduling, but it should be possible.
jm7
David Anderson
<[email protected]
ey.edu> To
Sent by: [email protected]
<boinc_dev-bounce cc
[email protected] [email protected]
u> Subject
Re: [boinc_dev] [boinc_alpha] EDF
and multi CPU tasks.
01/08/2010 11:57
AM
[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.
_______________________________________________
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.
