• Steven Rostedt (VMware)'s avatar
    sched/deadline: Use deadline instead of period when calculating overflow · 2317d5f1
    Steven Rostedt (VMware) authored
    I was testing Daniel's changes with his test case, and tweaked it a
    little. Instead of having the runtime equal to the deadline, I
    increased the deadline ten fold.
    
    Daniel's test case had:
    
    	attr.sched_runtime  = 2 * 1000 * 1000;		/* 2 ms */
    	attr.sched_deadline = 2 * 1000 * 1000;		/* 2 ms */
    	attr.sched_period   = 2 * 1000 * 1000 * 1000;	/* 2 s */
    
    To make it more interesting, I changed it to:
    
    	attr.sched_runtime  =  2 * 1000 * 1000;		/* 2 ms */
    	attr.sched_deadline = 20 * 1000 * 1000;		/* 20 ms */
    	attr.sched_period   =  2 * 1000 * 1000 * 1000;	/* 2 s */
    
    The results were rather surprising. The behavior that Daniel's patch
    was fixing came back. The task started using much more than .1% of the
    CPU. More like 20%.
    
    Looking into this I found that it was due to the dl_entity_overflow()
    constantly returning true. That's because it uses the relative period
    against relative runtime vs the absolute deadline against absolute
    runtime.
    
      runtime / (deadline - t) > dl_runtime / dl_period
    
    There's even a comment mentioning this, and saying that when relative
    deadline equals relative period, that the equation is the same as using
    deadline instead of period. That comment is backwards! What we really
    want is:
    
      runtime / (deadline - t) > dl_runtime / dl_deadline
    
    We care about if the runtime can make its deadline, not its period. And
    then we can say "when the deadline equals the period, the equation is
    the same as using dl_period instead of dl_deadline".
    
    After correcting this, now when the task gets enqueued, it can throttle
    correctly, and Daniel's fix to the throttling of sleeping deadline
    tasks works even when the runtime and deadline are not the same.
    Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: default avatarDaniel Bristot de Oliveira <bristot@redhat.com>
    Cc: Juri Lelli <juri.lelli@arm.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Luca Abeni <luca.abeni@santannapisa.it>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Romulo Silva de Oliveira <romulo.deoliveira@ufsc.br>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tommaso Cucinotta <tommaso.cucinotta@sssup.it>
    Link: http://lkml.kernel.org/r/02135a27f1ae3fe5fd032568a5a2f370e190e8d7.1488392936.git.bristot@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    2317d5f1
Name
Last commit
Last update
..
Makefile Loading commit data...
autogroup.c Loading commit data...
autogroup.h Loading commit data...
clock.c Loading commit data...
completion.c Loading commit data...
core.c Loading commit data...
cpuacct.c Loading commit data...
cpuacct.h Loading commit data...
cpudeadline.c Loading commit data...
cpudeadline.h Loading commit data...
cpufreq.c Loading commit data...
cpufreq_schedutil.c Loading commit data...
cpupri.c Loading commit data...
cpupri.h Loading commit data...
cputime.c Loading commit data...
deadline.c Loading commit data...
debug.c Loading commit data...
fair.c Loading commit data...
features.h Loading commit data...
idle.c Loading commit data...
idle_task.c Loading commit data...
loadavg.c Loading commit data...
rt.c Loading commit data...
sched.h Loading commit data...
stats.c Loading commit data...
stats.h Loading commit data...
stop_task.c Loading commit data...
swait.c Loading commit data...
topology.c Loading commit data...
wait.c Loading commit data...