sched_wakeup_granularity_ns in CFS correctly designed or not?

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@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 

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@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 

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@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@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 

sched_wakeup_granularity_ns in CFS correctly designed or not?

[Rik van Riel]

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.
-------------- 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/963736f9/attachment.bin 

sched_wakeup_granularity_ns in CFS correctly designed or not?

[Rohith R]

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

sched_wakeup_granularity_ns in CFS correctly designed or not?

[Rik van Riel]

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.
-------------- 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/384c3afc/attachment.bin