aboutsummaryrefslogtreecommitdiffstats
path: root/kernel/sched
diff options
context:
space:
mode:
authorxiaofeng.yan <xiaofeng.yan@huawei.com>2014-08-25 23:15:41 -0400
committerIngo Molnar <mingo@kernel.org>2014-09-07 05:09:59 -0400
commit177ef2a6315ea7bf173653182324e1dcd08ffeaa (patch)
tree0e32bf3f60350bc13b6eb4d3b11182b28cc9c8f5 /kernel/sched
parent6b44f519017b219a12b37173c7eef8dfce2c0100 (diff)
sched/deadline: Fix a precision problem in the microseconds range
An overrun could happen in function start_hrtick_dl() when a task with SCHED_DEADLINE runs in the microseconds range. For example, if a task with SCHED_DEADLINE has the following parameters: Task runtime deadline period P1 200us 500us 500us The deadline and period from task P1 are less than 1ms. In order to achieve microsecond precision, we need to enable HRTICK feature by the next command: PC#echo "HRTICK" > /sys/kernel/debug/sched_features PC#trace-cmd record -e sched_switch & PC#./schedtool -E -t 200000:500000:500000 -e ./test The binary test is in an endless while(1) loop here. Some pieces of trace.dat are as follows: <idle>-0 157.603157: sched_switch: :R ==> 2481:4294967295: test test-2481 157.603203: sched_switch: 2481:R ==> 0:120: swapper/2 <idle>-0 157.605657: sched_switch: :R ==> 2481:4294967295: test test-2481 157.608183: sched_switch: 2481:R ==> 2483:120: trace-cmd trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test We can get the runtime of P1 from the information above: runtime = 157.608183 - 157.605657 runtime = 0.002526(2.526ms) The correct runtime should be less than or equal to 200us at some point. The problem is caused by a conditional judgment "delta > 10000" in function start_hrtick_dl(). Because no hrtimer start up to control the rest of runtime when the reset of runtime is less than 10us. So the process will continue to run until tick-period is coming. Move the code with the limit of the least time slice from hrtick_start_fair() to hrtick_start() because the EDF schedule class also needs this function in start_hrtick_dl(). To fix this problem, we call hrtimer_start() unconditionally in start_hrtick_dl(), and make sure the scheduling slice won't be smaller than 10us in hrtimer_start(). Signed-off-by: Xiaofeng Yan <xiaofeng.yan@huawei.com> Reviewed-by: Li Zefan <lizefan@huawei.com> Acked-by: Juri Lelli <juri.lelli@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1409022941-5880-1-git-send-email-xiaofeng.yan@huawei.com [ Massaged the changelog and the code. ] Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'kernel/sched')
-rw-r--r--kernel/sched/core.c10
-rw-r--r--kernel/sched/deadline.c5
-rw-r--r--kernel/sched/fair.c8
3 files changed, 10 insertions, 13 deletions
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a773c919d88d..8d00f4a8c126 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -455,7 +455,15 @@ static void __hrtick_start(void *arg)
455void hrtick_start(struct rq *rq, u64 delay) 455void hrtick_start(struct rq *rq, u64 delay)
456{ 456{
457 struct hrtimer *timer = &rq->hrtick_timer; 457 struct hrtimer *timer = &rq->hrtick_timer;
458 ktime_t time = ktime_add_ns(timer->base->get_time(), delay); 458 ktime_t time;
459 s64 delta;
460
461 /*
462 * Don't schedule slices shorter than 10000ns, that just
463 * doesn't make sense and can cause timer DoS.
464 */
465 delta = max_t(s64, delay, 10000LL);
466 time = ktime_add_ns(timer->base->get_time(), delta);
459 467
460 hrtimer_set_expires(timer, time); 468 hrtimer_set_expires(timer, time);
461 469
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index d21a8e0259d2..cc4eb89019c1 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,7 @@ static void check_preempt_curr_dl(struct rq *rq, struct task_struct *p,
997#ifdef CONFIG_SCHED_HRTICK 997#ifdef CONFIG_SCHED_HRTICK
998static void start_hrtick_dl(struct rq *rq, struct task_struct *p) 998static void start_hrtick_dl(struct rq *rq, struct task_struct *p)
999{ 999{
1000 s64 delta = p->dl.dl_runtime - p->dl.runtime; 1000 hrtick_start(rq, p->dl.runtime);
1001
1002 if (delta > 10000)
1003 hrtick_start(rq, p->dl.runtime);
1004} 1001}
1005#endif 1002#endif
1006 1003
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 02fc949eb348..50d2025c1777 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3897,14 +3897,6 @@ static void hrtick_start_fair(struct rq *rq, struct task_struct *p)
3897 resched_curr(rq); 3897 resched_curr(rq);
3898 return; 3898 return;
3899 } 3899 }
3900
3901 /*
3902 * Don't schedule slices shorter than 10000ns, that just
3903 * doesn't make sense. Rely on vruntime for fairness.
3904 */
3905 if (rq->curr != p)
3906 delta = max_t(s64, 10000LL, delta);
3907
3908 hrtick_start(rq, delta); 3900 hrtick_start(rq, delta);
3909 } 3901 }
3910} 3902}