On Apr 22, 2009, at 4:01 AM, Paul D. Buck wrote:
>
> 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.
You might have been happier if I never looked at the code ...
NOw I want to know why on an 8 CPU system boinc thinks I am scheduling
8.72 something CPUs ...
I want to assume that the QCN task might account for the 0.727268 CPUs
though the number is high and I don't see where the addition works to
add that in the way the code is structured. The NCI tasks are already
rescheduled by the time you start adding up the NCPU value in the pre-
empt loop ...
4/22/2009 3:45:13 AM [cpu_sched_debug] finished preempt loop,
ncpus_used 8.727268
_______________________________________________
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.
