sched_wakeup_granularity_ns in CFS correctly designed or not?

[Rohith R]

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.
systutorials.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 ?

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
?

- RR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170611/6b64646e/attachment.html