sched/rt: Do not account zero delta_exec in update_curr_rt()
authorKirill Tkhai <[email protected]>
Wed, 30 Jan 2013 12:50:36 +0000 (16:50 +0400)
committerIngo Molnar <[email protected]>
Thu, 31 Jan 2013 09:31:13 +0000 (10:31 +0100)
There are several places of consecutive calls of
dequeue_task_rt() and put_prev_task_rt() in the scheduler.
For example, function rt_mutex_setprio() does it.

The both calls lead to update_curr_rt(), the second of it
receives zeroed delta_exec. The only effective action in this
case is call of sched_rt_avg_update(), which can change
rq->age_stamp and rq->rt_avg. But it is possible in case of
""floating"" rq->clock. This fact is not reasonable to be
accounted. Another actions do nothing.

Signed-off-by: Kirill V Tkhai <[email protected]>
Acked-by: Steven Rostedt <[email protected]>
Cc: Peter Zijlstra <[email protected]>
CC: linux-rt-users <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
kernel/sched/rt.c

index 2f69ca997826337bfd83b8f47199cf6e6c544b90..94abca4d9cf57198383a10ee4fcb1982f3e71000 100644 (file)
@@ -925,8 +925,8 @@ static void update_curr_rt(struct rq *rq)
                return;
 
        delta_exec = rq->clock_task - curr->se.exec_start;
-       if (unlikely((s64)delta_exec < 0))
-               delta_exec = 0;
+       if (unlikely((s64)delta_exec <= 0))
+               return;
 
        schedstat_set(curr->se.statistics.exec_max,
                      max(curr->se.statistics.exec_max, delta_exec));