It would be good if we had a suite of tests to run CPU schedulers through
and a proposed CPU scheduler change could be tested quickly. I proposed
setting this up as the "BOINC" project tasks. The memorex in this case
could get us answers about the effectiveness much faster than live does.
The problem is that the edge conditions do not happen frequently. Most of
the time on most machines any CPU scheduler will work. It is only
sometimes that there is a major problem where some task will be reported
weeks late, or a resource is ignored for a day or two...
jm7
"Paul D. Buck"
<p.d.b...@comcast
.net> To
Sent by: BOINC Developers Mailing List
<boinc_dev-bounce <[email protected]>
[email protected] cc
u> [email protected]
Subject
Re: [boinc_dev] [boinc_alpha] EDF
01/08/2010 12:02 and multi CPU tasks.
PM
When we are easily able to create cases "live", why do we need memorex?
On Jan 8, 2010, at 8:09 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.
>
> This is a case that should be solved. Returning a task weeks late when
all
> tasks could have been completed on time is in my opinion a major oops.
>
> 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.
>
> jm7
>
>
>
> David Anderson
> <[email protected]
> ey.edu> To
> Sent by: [email protected]
> <boinc_alpha-boun cc
> [email protected]. [email protected], BOINC
> edu> Alpha Mailing List
> <[email protected]>
> Subject
> 01/07/2010 05:42 Re: [boinc_alpha] EDF and multi CPU
> PM tasks.
>
>
>
>
>
>
>
>
>
>
> The scheduling policy for multithread apps is the result of many
> iterations.
> We're at a point where a change to improve one scenario is
> likely to worsen other scenarios.
>
> I suggest that we resurrect the client simulator to study proposed
> changes "in the lab".
> It will require a bit of work to make the simulator handle
> multithread and GPU apps; is anyone interested in doing this?
>
> -- David
>
> [email protected] wrote:
>> I have a dual CPU system that is currently running Aqua. The run time
> for
>> Aqua is grossly over estimated. However, I believe that the task would
> be
>> in EDF anyway based on the speed of the computer and my estimate of the
>> length of the task.
>>
>> Now for the problem:
>>
>> I have about a dozen other tasks on the host, most of which have
> deadlines
>> before the Aqua task (the exceptions are the CPDN and CPDN Beta tasks).
> It
>> appears that two of these tasks have to enter EDF (or N for a system
with
>> more than 2 CPUs) in order to override the processing of the Aqua task.
>> What happens if there is one task left with an earlier deadline than the
>> Aqua task? It appears that it will not be run until after the Aqua task
> is
>> finished - about a week after the deadline for the earlier deadline task
> in
>> this case.
>>
>> Possible solutions:
>>
>> 1) When generating the list of tasks to run, skip tasks that do not
have
>> the processor count to run now. Note that if skipping a task that needs
>> EDF because of this, it would be a good idea to pick a task with an
> earlier
>> deadline than the task that has the deadline problem and insufficient
>> resources. This increases the probabilities of everything meeting
> deadline
>> in this case. It also means that there is not an idle CPU.
>>
>> 2) Order all tasks in priority order and let enforcement sort out what
> can
>> to run now based on such things as CPU/GPU availability and RAM
>> availability.
>>
>> jm7
>>
>
> _______________________________________________
> boinc_alpha mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
> 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.
_______________________________________________
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.
