If implement with my other suggestion about having a separate test for
telling if a preemption is needed or just a high priority for the CPU, then
it should not impact preemptions.
I would say that both need testing though. I had thought about it, but am
uncertain how it would affect preemption on other setups with the current
preemption code. It might cause more, it might cause fewer, and it might
just cause different tasks to be preempted.
jm7
"Paul D. Buck"
<p.d.b...@comcast
.net> To
[email protected]
02/03/2010 01:51 cc
PM [email protected], David
Anderson <[email protected]>
Subject
Re: [boinc_dev] Thoughts on STD.
Well, for those of us whose ISP has a bad habit of dropping off-line at
times, a queue is needful ...
And this change I find interesting that you propose it because you do not
think it will be a problem for your configurations, with out much
consideration of other configurations.
On Feb 3, 2010, at 8:10 AM, [email protected] wrote:
> Maybe in some cases. What I see on my computers is that the tasks with a
> high STD are the tasks from projects with a high resource share, and all
> other tasks eventually end up running in EDF with the exception of my i7
> where projects with just about any STD get to run as it does not tend to
> keep many non started tasks around (always on, and about 60 projects
> attached so no need for much of a queue).
>
> jm7
>
>
>
> "Paul D. Buck"
> <p.d.b...@comcast
> .net> To
> [email protected]
> 02/03/2010 11:00 cc
> AM David Anderson
> <[email protected]>,
> [email protected]
> Subject
> Re: [boinc_dev] Thoughts on STD.
>
>
>
>
>
>
>
>
>
>
>> 3) The "neutral" position changes from 0 to + 1 day of STD. This means
>> that new work would be preferred by rr_sim over work that has been on
the
>> system for a while.
>
> Would this not perpetuate some of the issues we are having now? With
work
> being put off until it is in deadline peril and then have to be run in HP
> mode?
>
> A project that issues work in fits and starts would be constantly
"jumping
> the queue" as the queue was purged and then work was obtained.
>
> On multi-core systems this might not be that big of a deal unless we
start
> to see task preemtion again as the new tasks bump already executing tasks
> off the list...
>
> On Feb 3, 2010, at 7:27 AM, [email protected] wrote:
>
>>
>> I have a proposal that may fix all of the STD problems.
>>
>> 1) Clip the DCF at +/- 1 Day (as is done currently).
>> 2) Use the overall resource fraction to determine the rate of change.
>> 3) Do not shift so that the mean is kept at 0.
>> 4) Tasks with no work on the system have the STD increase at the same
> rate
>> as they would if they had work on the system.
>>
>> Consequences:
>>
>> 1) No penalty or gain for being out of work on the system for a few
>> seconds.
>> 2) A project is not penalized forever for using extra CPU time in the
>> past. If the project does not have work on the system for long enough,
> it
>> starts from a "neutral" position.
>> 3) The "neutral" position changes from 0 to + 1 day of STD. This means
>> that new work would be preferred by rr_sim over work that has been on
the
>> system for a while.
>>
>> jm7
>>
>> _______________________________________________
>> 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.
