sched_wakeup_granularity_ns in CFS correctly designed or not?

[Rik van Riel]

On Sun, 2017-06-11 at 11:15 +0530, Rohith R wrote:
> Hi,
> 
> I was working on the Linux CFS scheduler and came across this
> tuneable parameter called `sched_wakeup_granularity_ns`. The use of
> this goes as follows as described in [this paper](http://rouskas.csc.
> ncsu.edu/Publications/Conferences/ICC-SPS-2015.pdf).
> 
> > This parameter controls the wake-up latency of a task, i.e., the
> amount of time it must lapse before it can preempt the current task.
> 
> Further looking up on this parameter from [here](https://www.systutor
> ials.com/239998/sched_min_granularity_ns-sched_latency_ns-cfs-affect-
> timeslice-processes/) :
> 
> > If the difference between the virtual run time of current running
> process and the virtual run time of preempting process is bigger than
> the virtual run time of sched_wakeup_granularity_ns (here, transfer
> sched_wakeup_granularity_ns to a virtual run time with preempting
> process’s weight), the preemption happens.
> 
> The default value of this in my system is 2.5 milli seconds.
> 
> My question : If a process with a deadline <= 2.5 ms comes at time
> another low priority process is executing then, it won't get its
> chance to execute because of this minimum granularity and will always
> miss its deadline.
> 
> Am I right in my claim ? Why is the Linux kernel designed like that ?

CFS does not have deadlines at all. You may be
confusing the CFS scheduler and the deadline scheduler.

The wakeup granularity in CFS is used to determine
whether or not the scheduler should bother preempting
the currently running task if a higher priority task
becomes runnable.

If the remaining amount of time in the currently running
task's time slice is small, we are better off letting
it run until the end of its time slice, before scheduling
in the newly woken task.

> Of course we can set this parameter to 0 ms and re-compile the
> kernel, but don't tasks with deadlines of 2.5 ms occur frequently in
> day to day life ? Video decoders, sound processing apps, and other
> latency critical workloads ?

Why recompile the kernel, when you can tune the value
through /proc/sys/kernel/sched_wakeup_granularity_ns ?

-- 
All Rights Reversed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170611/90b6d577/attachment.bin