sched_wakeup_granularity_ns in CFS correctly designed or not?
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
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.
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@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.
On Sun, 2017-06-11 at 21:38 +0530, Rohith R wrote:
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 ?
OK, let me get this straight: 1) Your application has a deadline. 2) You do not tell the kernel of that deadline. 3) You want to know if the kernel will keep the promise you never told it about? Is that really your question? -- All Rights Reversed.
OK, let me get this straight: 1) Your application has a deadline. 2) You do not tell the kernel of that deadline. 3) You want to know if the kernel will keep the promise you never told it about?
Yes. All I am saying is that by keeping a *sched_wakeup_granularity_ns *parameter as 2.5 ms. A process which is waken up has to wait for that much amount of time if any other (non-important) process is executing. Now I am saying that the way CFS seems to be designed it will never make a process which wakes up and has a deadline < 2.5 ms meet its deadline. Now why does this scenario matter. This may occur in real workloads like video processing etc. I do not want any guarantee that CFS will meet deadline that I did not even give it (or its not even aware of). But one sure would like a guarantee that CFS surely will not fail all the time in such scenarios (which is my claim). Is that really your question? I hope the question makes sense now.
On Sun, 2017-06-11 at 22:26 +0530, Rohith R wrote:
OK, let me get this straight: 1) Your application has a deadline. 2) You do not tell the kernel of that deadline. 3) You want to know if the kernel will keep the promise you never told it about?
Yes. All I am saying is that by keeping a sched_wakeup_granularity_ns parameter as 2.5 ms. A process which is waken up has to wait for that much amount of time if any other (non- important) process is executing. Now I am saying that the way CFS seems to be designed it will never make a process which wakes up and has a deadline < 2.5 ms meet its deadline.
Now why does this scenario matter. This may occur in real workloads like video processing etc.
How much video processing? If the amount of computation time is 3ms, that means the video processing program needs to program its wakeup time at least 3ms before the time it needs to have the data ready. There will likely be some buffering involved, too, so it can safely move its deadline a little further, and have time to spare. When the system is overloaded, the video processing program may not get as much CPU time as it needs, but on a system that is not overloaded, chances are it will be fine. If you need a guarantee, use SCHED_DEADLINE. -- All Rights Reversed.
participants (2)
-
Rik van Riel -
Rohith R