From: Luca Abeni <luca.abeni@unitn.it>
To: Tommaso Cucinotta <tommaso.cucinotta@sssup.it>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Christoph Lameter <cl@linux.com>,
linux-rt-users <linux-rt-users@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature
Date: Mon, 7 Nov 2016 19:06:20 +0100 [thread overview]
Message-ID: <20161107190620.1b629d82@utopia> (raw)
In-Reply-To: <470b4cdc-1196-99e4-ee70-6e058e0284e0@sssup.it>
On Mon, 7 Nov 2016 19:03:08 +0100
Tommaso Cucinotta <tommaso.cucinotta@sssup.it> wrote:
> On 07/11/2016 14:51, Daniel Bristot de Oliveira wrote:
> > Hi Tommaso,
>
> Hi,
>
> I'm cc-ing Luca for GRUB et al., pls find a few further notes below...
Thanks Tommaso! I've seen the email on the linux-rt-users mailing list,
and I'll reply there about GRUB...
Thanks,
Luca
>
> > 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.
>
> sure, and having an option to let it run for longer, if there's
> nothing else running in the system, is still interesting for pretty
> much similar reasons to those being discussed in this thread ...
>
> > 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.....
>
> yes, the main difference being: GRUB will let a DL task run for longer
> than its own runtime, but still let it starve anything below (RT as
> well as OTHER tasks); perhaps Luca (cc) has some further comment on
> this...
>
> Thanks,
>
> T.
>
> > 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
> >
>
>
next prev parent reply other threads:[~2016-11-07 18:26 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-07 8:17 [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Daniel Bristot de Oliveira
2016-11-07 10:31 ` Tommaso Cucinotta
2016-11-07 13:51 ` Daniel Bristot de Oliveira
2016-11-07 18:03 ` Tommaso Cucinotta
2016-11-07 18:06 ` Luca Abeni [this message]
2016-11-08 7:55 ` luca abeni
2016-11-08 10:30 ` Juri Lelli
2016-11-07 16:55 ` Christoph Lameter
2016-11-07 18:32 ` Steven Rostedt
2016-11-07 18:49 ` Daniel Bristot de Oliveira
2016-11-07 19:16 ` Steven Rostedt
2016-11-07 19:30 ` Christoph Lameter
2016-11-07 19:47 ` Steven Rostedt
2016-11-07 19:54 ` Christoph Lameter
2016-11-07 20:00 ` Steven Rostedt
2016-11-07 20:06 ` Daniel Bristot de Oliveira
2016-11-07 20:16 ` Steven Rostedt
2016-11-07 20:33 ` Daniel Bristot de Oliveira
2016-11-07 20:44 ` Steven Rostedt
2016-11-08 9:22 ` [PATCH] sched/rt: Change default setup for RT THROTTLING Daniel Bristot de Oliveira
2016-11-08 23:42 ` [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Christoph Lameter
2016-11-07 18:22 ` Clark Williams
2016-11-07 18:30 ` Steven Rostedt
2016-11-07 18:38 ` Daniel Bristot de Oliveira
2016-11-07 18:39 ` Clark Williams
2016-11-08 11:59 ` Peter Zijlstra
2016-11-08 14:07 ` Steven Rostedt
2016-11-08 16:51 ` Peter Zijlstra
2016-11-08 17:17 ` Steven Rostedt
2016-11-08 18:05 ` Peter Zijlstra
2016-11-08 19:29 ` Daniel Bristot de Oliveira
2016-11-08 19:50 ` Peter Zijlstra
2016-11-09 13:33 ` Daniel Bristot de Oliveira
[not found] ` <CAA7rmPF0nQb9721MQWurRCy7E3X46hAy2qV=joK=z5U-t70NOg@mail.gmail.com>
2016-11-11 18:46 ` Christoph Lameter
2016-11-11 22:53 ` Peter Zijlstra
2016-11-13 18:53 ` Christoph Lameter
2016-11-14 9:20 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161107190620.1b629d82@utopia \
--to=luca.abeni@unitn.it \
--cc=bristot@redhat.com \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tommaso.cucinotta@sssup.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).