diff options
author | Xunlei Pang <xlpang@redhat.com> | 2016-04-14 20:19:28 +0800 |
---|---|---|
committer | Ingo Molnar <mingo@kernel.org> | 2016-04-23 14:20:43 +0200 |
commit | fec148c000d0f9ac21679601722811eb60b4cc52 (patch) | |
tree | 55c09a46a59230d87c7a2f62f48c91bc75398584 /kernel/sched/rt.c | |
parent | 9fd81dd5ce0b12341c9f83346f8d32ac68bd3841 (diff) | |
download | linux-stable-fec148c000d0f9ac21679601722811eb60b4cc52.tar.gz linux-stable-fec148c000d0f9ac21679601722811eb60b4cc52.tar.bz2 linux-stable-fec148c000d0f9ac21679601722811eb60b4cc52.zip |
sched/deadline: Fix a bug in dl_overflow()
I got a minus(very big) dl_b->total_bw during my deadline tests.
# grep dl /proc/sched_debug
dl_rq[0]:
.dl_nr_running : 0
.dl_bw->bw : 996147
.dl_bw->total_bw : -222297900
Something unusual must have happened.
After some digging, I finally noticed that when changing a deadline
task to normal(cfs), and changing it back to deadline immediately,
after it died, we will got the wrong dl_bw->total_bw.
The root cause is in dl_overflow(), it has:
if (new_bw == p->dl.dl_bw)
return 0;
1) When a deadline task is changed to !deadline task, it will start
dl timer in switched_from_dl(), and retain previous deadline parameter
till the timer expires.
2) If we change it back to deadline with the same bandwidth parameter
before the timer expires, as it keeps the old bandwidth although it
is not a deadline task. dl_overflow() simply returns success without
updating the right data, and got the wrong dl_bw->total_bw.
The solution is simple, if @p is not deadline, don't return.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Juri Lelli <juri.lelli@arm.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1460636368-1993-1-git-send-email-xlpang@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'kernel/sched/rt.c')
0 files changed, 0 insertions, 0 deletions