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 <[email protected]> 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.
_______________________________________________ Kernelnewbies mailing list [email protected] https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
