On Apr 22, 2009, at 4:17 PM, David Anderson wrote:
> "now" is a member of CLIENT_STATE.
> In member functions of CLIENT_STATE it's referred to as "now";
> elsewhere it's referred to as "gstate.now".
> There is no function now().
>
> Now that that's straightened out, maybe we can return to the issue
> of why preemptions happen too soon.
Each time the function enforce_schedule() is run the lines 845-848 set
all tasks running (active) to preempted:
for (i=0; i< active_tasks.active_tasks.size(); i++) {
atp = active_tasks.active_tasks[i];
atp->next_scheduler_state = CPU_SCHED_PREEMPTED;
}
Which means that every cycle we assume that ALL tasks are preemptable
and should be preempted at each call to this function.
In that we have already marked the tasks as preempted the code in
905-939 is so much wasted time.
Which always brings me back to my FIRST question. Why are we running
this code this often?
If it is to detect TSI, then the logic is all wrong.
In fact, if we stick to strict rules this function would only be
called in two cases:
1) When a resource goes idle
2) When TSI is reached
However, in our mania to meet another goal, we obsessively call this
function. That goal is to not miss deadlines.
But this still begs the question. Does obsessively calling this
function really help us to meet that goal, or to put it another way,
can we meet that goal without calling this function this often?
I think we can.
The problem we see is a side-effect of the idea that if the cost is
low to do something then doing something a lot of times has no
negative effects. On older slower systems this is one reason why this
design flaw has less effect, the function is called less often. Lower
call rate, less of a problem. On my system it is called as often as 6
times a minute ... whole different environment.
> of why preemption happen too soon.
Because of the way we have defined and detect the potential of a
deadline miss.
WIth a long TSI, as I have, short tasks with a shorter than normal
deadline immediately trigger a context switch.
_______________________________________________
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.
