linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> >
> 
> 

  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).