Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1516210

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

From Daniel Bristot de Oliveira <bristot@redhat.com>
Newsgroups linux.kernel
Subject Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature
Date 2016-11-07 15:00 +0100
Message-ID <sASCX-3R8-27@gated-at.bofh.it> (permalink)
References <sANjQ-mL-3@gated-at.bofh.it> <sAPvj-1Se-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi Tommaso,

On 11/07/2016 11:31 AM, Tommaso Cucinotta wrote:
> as anticipated live to Daniel:
> -) +1 for the general concept, we'd need something similar also for
> SCHED_DEADLINE

Resumed: the sum of the runtime of deadline tasks will not be greater
than the "to_ratio(global_rt_period(), global_rt_runtime())" - see
init_dl_bw(). Therefore, DL rq will not be throttle by the RT throttling
mechanism.

Extended: RT tasks' throttling aims to bound, for all CPUS of a domain -
when RT_RUNTIME_SHARING sharing is enabled; or per-rq - when
RT_RUNTIME_SHARING is disabled; the amount of time that RT tasks can run
continuously, in such way to provide some CPU time for non-real-time
tasks to run. RT tasks need this global/local throttling mechanism to
avoid the starvation of non-rt tasks because RT tasks do not have a
limited runtime - RT task (or taskset) can run for an infinity runtime.

DL tasks' throttling has another meaning. DL tasks' throttling aims to
avoid *a* DL task for running for more than *its own* pre-allocated runtime.

The sum of allocated runtime for all DL tasks will not to be greater
than RT throttling enforcement runtime. The DL scheduler admission
control already avoids this by limiting the amount of CPU time all DL
tasks can consume (see init_dl_bw()). So, DL tasks are avoid ind the
"global" throttling on before hand - in the admission control.

GRUB might implement something <<similar>> for the DEADLINE scheduler.
With GRUB, a deadline tasks will have more runtime than previously
set/granted..... But I am quite sure it will still be bounded by the sum
of the already allocated DL runtime, that will continue being smaller
than "to_ratio(global_rt_period(), global_rt_runtime())".

Am I missing something?

> -) only issue might be that, if a non-RT task wakes up after the
> unthrottle, it will have to wait, but worst-case it will have a chance
> in the next throttling window

In the current default behavior (RT_RUNTIME_SHARING), in a domain with
more than two CPUs, the worst case easily become "infinity," because a
CPU can borrow runtime from another CPU. There is no guarantee for
minimum latency for non-rt tasks. Anyway, if the user wants to provide
such guarantee, they just need not enable this feature, while disabling
RT_RUNTIME_SHARING (or run the non-rt task as a deadline task ;-))

> -) an alternative to unthrottling might be temporary class downgrade to
> sched_other, but that might be much more complex, instead this Daniel's
> one looks quite simple

Yeah, decrease the priority of the task would be something way more
complicated and prone to errors. RT tasks would need to reduce its
priority to a level higher than the IDLE task, but lower than SCHED_IDLE...

> -) when considering also DEADLINE tasks, it might be good to think about
> how we'd like the throttling of DEADLINE and RT tasks to inter-relate,
> e.g.:

Currently, DL tasks are limited (in the bw control) to the global RT
throttling limit...

I think that this might be an extension to GRUB... that is extending the
current behavior... so... things for the future - and IMHO it is another
topic - way more challenging.

Comments are welcome :-)

-- Daniel

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] sched/rt: RT_RUNTIME_GREED sched feature Daniel Bristot de Oliveira <bristot@redhat.com> - 2016-11-07 09:20 +0100
  Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Tommaso Cucinotta <tommaso.cucinotta@sssup.it> - 2016-11-07 11:40 +0100
    Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Daniel Bristot de Oliveira <bristot@redhat.com> - 2016-11-07 15:00 +0100
      Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Tommaso Cucinotta <tommaso.cucinotta@sssup.it> - 2016-11-07 19:10 +0100
        Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Luca Abeni <luca.abeni@unitn.it> - 2016-11-07 19:30 +0100
      Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature luca abeni <lucabe72@gmail.com> - 2016-11-08 09:00 +0100
      Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Juri Lelli <juri.lelli@arm.com> - 2016-11-08 11:40 +0100
  Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Christoph Lameter <cl@linux.com> - 2016-11-07 18:00 +0100
    Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Steven Rostedt <rostedt@goodmis.org> - 2016-11-07 19:40 +0100
      Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Daniel Bristot de Oliveira <daniel@bristot.me> - 2016-11-07 19:50 +0100
        Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Steven Rostedt <rostedt@goodmis.org> - 2016-11-07 20:20 +0100
      Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Christoph Lameter <cl@linux.com> - 2016-11-07 20:40 +0100
        Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Christoph Lameter <cl@linux.com> - 2016-11-07 21:00 +0100
          Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Steven Rostedt <rostedt@goodmis.org> - 2016-11-07 21:10 +0100
            Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Daniel Bristot de Oliveira <daniel@bristot.me> - 2016-11-07 21:10 +0100
              Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Steven Rostedt <rostedt@goodmis.org> - 2016-11-07 21:20 +0100
                Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Daniel Bristot de Oliveira <daniel@bristot.me> - 2016-11-07 21:40 +0100
                Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Steven Rostedt <rostedt@goodmis.org> - 2016-11-07 21:50 +0100
                [PATCH] sched/rt: Change default setup for RT THROTTLING Daniel Bristot de Oliveira <daniel@bristot.me> - 2016-11-08 10:30 +0100
                Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Christoph Lameter <cl@linux.com> - 2016-11-09 00:50 +0100
        Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Steven Rostedt <rostedt@goodmis.org> - 2016-11-07 21:10 +0100
  Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Clark Williams <williams@redhat.com> - 2016-11-07 19:30 +0100
    Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Steven Rostedt <rostedt@goodmis.org> - 2016-11-07 19:40 +0100
      Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Daniel Bristot de Oliveira <daniel@bristot.me> - 2016-11-07 19:50 +0100
      Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Clark Williams <williams@redhat.com> - 2016-11-07 20:00 +0100
  Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Peter Zijlstra <peterz@infradead.org> - 2016-11-08 13:30 +0100
    Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Steven Rostedt <rostedt@goodmis.org> - 2016-11-08 15:10 +0100
      Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Peter Zijlstra <peterz@infradead.org> - 2016-11-08 18:00 +0100
        Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Steven Rostedt <rostedt@goodmis.org> - 2016-11-08 18:20 +0100
          Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Peter Zijlstra <peterz@infradead.org> - 2016-11-08 19:10 +0100
            Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Daniel Bristot de Oliveira <bristot@redhat.com> - 2016-11-08 20:40 +0100
              Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Peter Zijlstra <peterz@infradead.org> - 2016-11-08 21:00 +0100
                Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Daniel Bristot de Oliveira <bristot@redhat.com> - 2016-11-09 14:40 +0100
                Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Christoph Lameter <cl@linux.com> - 2016-11-11 19:50 +0100

csiph-web