lkml.org 
[lkml]   [2014]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] Pre-emption control for userspace
On 03/25/2014 02:31 PM, ebiederm@xmission.com wrote:
>> Yes, it is indeed limited to a cooperating set of userspace
>> tasks/threads. Tasks/threads will explicitly choose to use this feature. It is a
>> no-op for every one else.
>
> It is absolutely not a no-op for me if my task can't be scheduled soon
> enough because your task executed sched-prempt.
>
> It means my latency goes up and the *random bad thing* will happen
> because I missed my deadline because I was not scheduled fast enough.
>

This patch changes only CFS, so SCHED_RR and SCHED_FIFO are not affected
by this change. Does CFS ever guarantee that any task will be scheduled
fast enough to meet its critical deadline? Shouldn't a system that
requires guarantees to meet deadline use SCHED_FIFO or SCHED_RR? Even if
a task that has an important deadline to meet and is ready to run, it
can be denied processor time simply based upon which other tasks are
ready to run, how long they have run previously and what their
priorities are. I don't see how CFS can guarantee temporal determinism
other than every task will get a chance to run in a finite time period.
Please do correct me if my understanding of CFS is flawed.

Any task that asks for extension of its current timeslice will get
charged this additional time in p->se.vruntime and cause it to move to
the right on rbtree. This amounts to a task borrowing time from its
future runtime as opposed to being able to get more processor time than
others.

>>> or (b) limiting this to just a small
>>> cooperating set of threads in a single cgroup.
>>
>> and that is almost what this patch does. It is not limited to a cgroup, rather
>> to the tasks/threads that ask to use this feature.
>
> Except you do not appear to be considering what could be scheduled in
> your tasks place.
>
> You allow any task to extend it's timeslice.

Would you recommend a policy that determines which tasks are allowed to
extend their timeslice?

>
> Which means I will get the question why does why does
> really_important_job only miss it's latency guarantees when running on
> the same box as sched_preempt_using_job?

I would expect a system that requires latency guarantees to be designed
using SCHED_FIFO or SCHED_RR, not SCHED_OTHER.

Hope this makes sense.

Thanks,
Khalid




\
 
 \ /
  Last update: 2014-03-25 23:01    [W:0.097 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site