Best would be to allow tasks to indicate "flexible" resource usage and in
that case, have BOINC suggest a number of CPUs to consume.  In that case,
if the tasks were tagged as flexible, the resource scheduler would indicate
that the 1 CPU task gets a CPU task, and a flexible task gets 3 CPUs.

This still leaves us with the case where the tasks are not tagged as
flexible.  In this case, an overage on CPUs might be allowed.  Best would
be if the user was allowed to set either the overage fraction or the
overage count either in CC_CONFIG or global_prefs.  BOINC would of course
have a default.

We still might want to have the ability to run a lower priority task that
uses fewer CPUs instead of a higher priority task that overloads the
system.

Eventually, the N CPU task will either be the task with the nearest
deadline in EDF, or it will be from the project with the highest LTD.

Note that running a task on an overloaded system is going to affect the DCF
for that project by raising it (in your example by 20%).

jm7


                                                                           
             David Anderson                                                
             <da...@ssl.berkel                                             
             ey.edu>                                                    To 
                                       john.mcl...@sybase.com              
             08/18/2009 01:22                                           cc 
             PM                        boinc_dev@ssl.berkeley.edu          
                                                                   Subject 
                                       Re: [boinc_dev] boinc_cvs Digest,   
                                       Vol 57, Issue 17                    
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Consider this case:
a 4-CPU system with a long high-priority 1-CPU job
and a bunch of 4-CPU jobs.
With your proposal,
it would run the 1-CPU job and the other 3 CPUs would be idle for a long
time.

What's the right thing to do here?
If we run the 4-CPU jobs, we reduce the amount of CPU time that
the 1-CPU job gets, possibly causing it to be late.
If we don't run them, we have 3 idle CPUs.

CPU pinning is possible but I'd rather avoid it.

Possible compromise: don't run a job if the # of threads
(i.e., sum of avg_ncpus) would exceed X*NCPUs,
where X is say 1.5.

This would run the 4-CPU jobs in the above case
(slowing down the 1-CPU job by 20%)
but it wouldn't run the 4-CPU job on top of 3 1-CPU jobs.

-- David

john.mcl...@sybase.com wrote:
> This does not really quite fix the problem.  Unfortunately, if you have
an
> N processor machine, a task that needs to run high priority, and an N
> processor task that wants to run, then you will have N+1 processors
> assigned unless N==1.  A worse example would have N-1 tasks with deadline
> pressure and requiring EDF and one N processor task that was next.  At
that
> point you would get 2*N -1 processors committed.
>
> What is needed is to have all of the tasks for the resource prioritized,
> and skip over an task if there are not enough resources to run that right
> now.  The next task in line would then start if there were enough
resources
> for that task to run.  This way, an N processor task would run if it were
> prioritize first, and all other tasks would be suspended at that point.




_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to