On Apr 22, 2009, at 12:24 AM, David Anderson wrote:
> There are many reports that the current client preempts
> jobs before their time slice is up, for no good reason (see below).
>
> The code that enforces time slicing (from client/cpu_sched.cpp)
> is as follows (line 913)
> preempt_atp = preemptable_tasks.back();
> if (rp->project->cpu_pwf.deadlines_missed_copy ||
> finished_time_slice(preempt_atp)) {
> ...
> preempt_atp->next_scheduler_state =
> CPU_SCHED_PREEMPTED;
>
> In other words, it only preempts a job if its time slice is up,
> or if there's a job in deadline trouble.
> finished_time_slice() is define on line 134:
>
> static inline bool finished_time_slice(ACTIVE_TASK* atp) {
> double time_running = gstate.now - atp-
> >run_interval_start_wall_time;
> bool running_beyond_sched_period = time_running >=
> gstate.global_prefs.cpu_scheduling_period();
> double time_since_checkpoint = gstate.now - atp-
> >checkpoint_wall_time;
> bool checkpointed_recently = time_since_checkpoint < 10;
> return (running_beyond_sched_period && checkpointed_recently);
> }
>
> I haven't been able to find the problem here.
> A big (virtual) prize will go to anyone who can.
I can't find the printer tag for that loop to be the guilty party. Or
to put it another way, I am not sure that is the place. I am running
with the flag on and I will look for that line to be triggered. In
the logs I do have I cannot find any instance of "[cpu_sched_debug]
preempting %s" ...
HOWEVER, if I search on "CPU_SCHED_PREEMPTED" I find 6 reverences,
including the most suspicious where (starting line 843):
// Set next_scheduler_state to preempt
//
for (i=0; i< active_tasks.active_tasks.size(); i++) {
atp = active_tasks.active_tasks[i];
atp->next_scheduler_state = CPU_SCHED_PREEMPTED;
}
It looks to me like you flag all running tasks for preemption ...
THEN you schedule tasks to be run, THEN you test to see if a task has
met the constraints. Or to put it another way, you preempt the task
before you test to see if the task should be preempted.
HOWEVER, this still begs the question if the test for deadline trouble
might not also be too sensitive.
Or to put it another way, if the time to run the most preemptable task
and the task with peril is less than the deadline should we be pre-
empting the task in the first place?
_______________________________________________
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.
