sched_wakeup_granularity_ns in CFS correctly designed or not?

[Rohith R]

Sure, CFS does not have any deadlines at all. But I am trying to measure
its performance w.r.t to some workloads having some periods and deadlines.
So in that case will the tasks having deadline of < 2.5 ms always miss the
deadline ?

On Sun, Jun 11, 2017 at 5:57 PM, Rik van Riel <riel at surriel.com> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170611/9cfe0fa5/attachment.html