sched_wakeup_granularity_ns in CFS correctly designed or not?

[riel@surriel.com (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