public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "James H. Anderson" <anderson@cs.unc.edu>
To: Raistlin <raistlin@linux.it>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Chris Friesen <cfriesen@nortel.com>,
	oleg@redhat.com, Frederic Weisbecker <fweisbec@gmail.com>,
	Darren Hart <darren@dvhart.com>,
	Johan Eker <johan.eker@ericsson.com>,
	"p.faure" <p.faure@akatech.ch>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Claudio Scordino <claudio@evidence.eu.com>,
	michael trimarchi <trimarchi@retis.sssup.it>,
	Fabio Checconi <fabio@gandalf.sssup.it>,
	Tommaso Cucinotta <cucinotta@sssup.it>,
	Juri Lelli <juri.lelli@gmail.com>,
	Nicola Manica <nicola.manica@disi.unitn.it>,
	Luca Abeni <luca.abeni@unitn.it>,
	Dhaval Giani <dhaval@retis.sssup.it>,
	Harald Gustafsson <hgu1972@gmail.com>,
	paulmck <paulmck@linux.vnet.ibm.com>,
	Bjoern Brandenburg <bbb@email.unc.edu>,
	"James H. Anderson" <anderson@cs.unc.edu>
Subject: Re: [RFC][PATCH 18/22] sched: add reclaiming logic to -deadline tasks
Date: Mon, 15 Nov 2010 13:37:06 -0500	[thread overview]
Message-ID: <4CE17DD2.3060807@cs.unc.edu> (raw)
In-Reply-To: <80992760-24F2-42AE-AF2D-15727F6A1C81@email.unc.edu>

Sorry for the delayed response... I think I must have inadvertently 
deleted this
email last week and Bjoern just mentioned it to me...
> On Fri, 2010-11-12 at 17:04 +0100, Peter Zijlstra wrote:
>   
>> On Fri, 2010-11-12 at 16:36 +0100, Raistlin wrote:
>>     
>>> But at this point I can't avoid asking. That model aims at _pure_
>>> hard real-time scheduling *without* resource reservation capabilities,
>>> provided it deals with temporal overruns by means of a probabilistic
>>> analysis, right? 
>>>       
>> From what I understood from it, its a soft real-time scheduling
>> algorithm with resource reservation. 
>>
>>     
> Mmm... I've gone through it (again!) quickly, and you're right, it
> mentions soft real-time, and I agree that for those systems average CET
> is better than worst CET. However, I'm not sure resource reservation is
> there... Not in the paper I have at least, but I may be wrong.
>
>   
>> The problem the stochastic execution time model tries to address is the
>> WCET computation mess, WCET computation is hard and often overly
>> pessimistic, resulting in under-utilized systems.
>>
>>     
> I know, and it's very reasonable. The point I'm trying to make is that
> resource reservation tries to address the very same issue.
> I am all but against this model, just want to be sure it's not too much
> in conflict to the other features we have, especially with resource
> reservation. Especially considering that --if I got the whole thing
> about this scheduler right-- resource reservation is something we really
> want, and I think UNC people would agree here, since I heard Bjorn
> stating this very clear both in Dresden and in Dublin. :-)
>
> BTW, I'm adding them to the Cc, seems fair, and more useful than all
> this speculation! :-P
>
> Bjorn, Jim, sorry for bothering. If you're interested, this is the very
> beginning of the whole thread:
> http://lkml.org/lkml/2010/10/29/67
>
> And these should be from where this specific discussion starts (I hope,
> the mirror is not updated yet I guess :-( ):
> http://lkml.org/lkml/2010/10/29/49
> http://groups.google.com/group/linux.kernel/msg/1dadeca435631b60
>
> Thanks and Regards,
> Dario
>   
If you're talking about our most recent "stochastic" paper, it is about 
supporting
soft real-time task systems on a multiprocessor where resource 
reservations are
used.  The main result of the paper is that if you provision the 
reservation for a
task slightly higher than it's average-case execution time, and if you use a
scheduling algorithm (like global EDF) that ensures bounded tardiness 
(w.r.t.
these reservations), then the task's expected tardiness will be bounded 
and the
expected bound does not depend on worst-case execution times.  I'm not 
sure if
slack-reallocation methods have come up in this discussion (sorry, I'm 
really
pressed for time and didn't look), but we didn't get into that in our 
paper.  However,
such methods would be easy to incorporate.  I think one of the most 
beautiful
aspects of this paper (which we didn't say enough about) is that the 
analysis
completely separates all the stochastic stuff from the reasoning needed to
derive tardiness bounds under a given scheduler.  In other words, you 
can simply
ignore all stochastic issues when reasoning about tardiness.  I gathered 
there was
some confusion about whether we were using resource reservations.  Such
reservations are actually crucial for our analysis as they allow 
independence to
be assumed across tasks.  And oh yeah: this work has nothing to do with hard
real-time and worst-case execution times are not used at all.

Just to make sure I don't end up creating more confusion, the paper I'm 
talking
about is this one:
http://www.cs.unc.edu/~anderson/papers/rtas11b.pdf

I hope this helps.

-Jim Anderson


  parent reply	other threads:[~2010-11-15 19:01 UTC|newest]

Thread overview: 135+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-29  6:18 [RFC][PATCH 00/22] sched: SCHED_DEADLINE v3 Raistlin
2010-10-29  6:25 ` [RFC][PATCH 01/22] sched: add sched_class->task_dead Raistlin
2010-10-29  6:27 ` [RFC][PATCH 02/22] sched: add extended scheduling interface Raistlin
2010-11-10 16:00   ` Dhaval Giani
2010-11-10 16:12     ` Dhaval Giani
2010-11-10 22:45       ` Raistlin
2010-11-10 16:17     ` Claudio Scordino
2010-11-10 17:28   ` Peter Zijlstra
2010-11-10 19:26     ` Peter Zijlstra
2010-11-10 23:33       ` Tommaso Cucinotta
2010-11-11 12:19         ` Peter Zijlstra
2010-11-10 22:17     ` Raistlin
2010-11-10 22:57       ` Tommaso Cucinotta
2010-11-11 13:32       ` Peter Zijlstra
2010-11-11 13:54         ` Raistlin
2010-11-11 14:08           ` Peter Zijlstra
2010-11-11 17:27             ` Raistlin
2010-11-11 14:05         ` Dhaval Giani
2010-11-10 22:24     ` Raistlin
2010-11-10 18:50   ` Peter Zijlstra
2010-11-10 22:05     ` Raistlin
2010-11-12 16:38   ` Steven Rostedt
2010-11-12 16:43     ` Peter Zijlstra
2010-11-12 16:52       ` Steven Rostedt
2010-11-12 19:19         ` Raistlin
2010-11-12 19:23           ` Steven Rostedt
2010-11-12 17:42     ` Tommaso Cucinotta
2010-11-12 19:21       ` Steven Rostedt
2010-11-12 19:24     ` Raistlin
2010-10-29  6:28 ` [RFC][PATCH 03/22] sched: SCHED_DEADLINE data structures Raistlin
2010-11-10 18:59   ` Peter Zijlstra
2010-11-10 22:06     ` Raistlin
2010-11-10 19:10   ` Peter Zijlstra
2010-11-12 17:11     ` Steven Rostedt
2010-10-29  6:29 ` [RFC][PATCH 04/22] sched: SCHED_DEADLINE SMP-related " Raistlin
2010-11-10 19:17   ` Peter Zijlstra
2010-10-29  6:30 ` [RFC][PATCH 05/22] sched: SCHED_DEADLINE policy implementation Raistlin
2010-11-10 19:21   ` Peter Zijlstra
2010-11-10 19:43   ` Peter Zijlstra
2010-11-11  1:02     ` Raistlin
2010-11-10 19:45   ` Peter Zijlstra
2010-11-10 22:26     ` Raistlin
2010-11-10 20:21   ` Peter Zijlstra
2010-11-11  1:18     ` Raistlin
2010-11-11 13:13       ` Peter Zijlstra
2010-11-11 14:13   ` Peter Zijlstra
2010-11-11 14:28     ` Raistlin
2010-11-11 14:17   ` Peter Zijlstra
2010-11-11 18:33     ` Raistlin
2010-11-11 14:25   ` Peter Zijlstra
2010-11-11 14:33     ` Raistlin
2010-11-14  8:54   ` Raistlin
2010-11-23 14:24     ` Peter Zijlstra
2010-10-29  6:31 ` [RFC][PATCH 06/22] sched: SCHED_DEADLINE handles spacial kthreads Raistlin
2010-11-11 14:31   ` Peter Zijlstra
2010-11-11 14:50     ` Dario Faggioli
2010-11-11 14:34   ` Peter Zijlstra
2010-11-11 15:27     ` Oleg Nesterov
2010-11-11 15:43       ` Peter Zijlstra
2010-11-11 16:32         ` Oleg Nesterov
2010-11-13 18:35           ` Peter Zijlstra
2010-11-13 19:58             ` Oleg Nesterov
2010-11-13 20:31               ` Peter Zijlstra
2010-11-13 20:51                 ` Peter Zijlstra
2010-11-13 23:31                   ` Peter Zijlstra
2010-11-15 20:06                     ` [PATCH] sched: Simplify cpu-hot-unplug task migration Peter Zijlstra
2010-11-17 19:27                       ` Oleg Nesterov
2010-11-17 19:42                         ` Peter Zijlstra
2010-11-18 14:05                           ` Oleg Nesterov
2010-11-18 14:24                             ` Peter Zijlstra
2010-11-18 15:32                               ` Oleg Nesterov
2010-11-18 14:09                       ` [tip:sched/core] " tip-bot for Peter Zijlstra
2010-11-11 14:46   ` [RFC][PATCH 06/22] sched: SCHED_DEADLINE handles spacial kthreads Peter Zijlstra
2010-10-29  6:32 ` [RFC][PATCH 07/22] sched: SCHED_DEADLINE push and pull logic Raistlin
2010-11-12 16:17   ` Peter Zijlstra
2010-11-12 21:11     ` Raistlin
2010-11-14  9:14     ` Raistlin
2010-11-23 14:27       ` Peter Zijlstra
2010-10-29  6:33 ` [RFC][PATCH 08/22] sched: SCHED_DEADLINE avg_update accounting Raistlin
2010-11-11 19:16   ` Peter Zijlstra
2010-10-29  6:34 ` [RFC][PATCH 09/22] sched: add period support for -deadline tasks Raistlin
2010-11-11 19:17   ` Peter Zijlstra
2010-11-11 19:31     ` Raistlin
2010-11-11 19:43       ` Peter Zijlstra
2010-11-11 23:33         ` Tommaso Cucinotta
2010-11-12 13:33         ` Raistlin
2010-11-12 13:45           ` Peter Zijlstra
2010-11-12 13:46       ` Luca Abeni
2010-11-12 14:01         ` Raistlin
2010-10-29  6:35 ` [RFC][PATCH 10/22] sched: add a syscall to wait for the next instance Raistlin
2010-11-11 19:21   ` Peter Zijlstra
2010-11-11 19:33     ` Raistlin
2010-10-29  6:35 ` [RFC][PATCH 11/22] sched: add schedstats for -deadline tasks Raistlin
2010-10-29  6:36 ` [RFC][PATCH 12/22] sched: add runtime reporting " Raistlin
2010-11-11 19:37   ` Peter Zijlstra
2010-11-12 16:15     ` Raistlin
2010-11-12 16:27       ` Peter Zijlstra
2010-11-12 21:12         ` Raistlin
2010-10-29  6:37 ` [RFC][PATCH 13/22] sched: add resource limits " Raistlin
2010-11-11 19:57   ` Peter Zijlstra
2010-11-12 21:30     ` Raistlin
2010-11-12 23:32       ` Peter Zijlstra
2010-10-29  6:38 ` [RFC][PATCH 14/22] sched: add latency tracing " Raistlin
2010-10-29  6:38 ` [RFC][PATCH 15/22] sched: add traceporints " Raistlin
2010-11-11 19:54   ` Peter Zijlstra
2010-11-12 16:13     ` Raistlin
2010-10-29  6:39 ` [RFC][PATCH 16/22] sched: add SMP " Raistlin
2010-10-29  6:40 ` [RFC][PATCH 17/22] sched: add signaling overrunning " Raistlin
2010-11-11 21:58   ` Peter Zijlstra
2010-11-12 15:39     ` Raistlin
2010-11-12 16:04       ` Peter Zijlstra
2010-10-29  6:42 ` [RFC][PATCH 19/22] rtmutex: turn the plist into an rb-tree Raistlin
2010-10-29  6:42 ` [RFC][PATCH 18/22] sched: add reclaiming logic to -deadline tasks Raistlin
2010-11-11 22:12   ` Peter Zijlstra
2010-11-12 15:36     ` Raistlin
2010-11-12 16:04       ` Peter Zijlstra
2010-11-12 17:41         ` Luca Abeni
2010-11-12 17:51           ` Peter Zijlstra
2010-11-12 17:54             ` Luca Abeni
2010-11-13 21:08             ` Raistlin
2010-11-12 18:07           ` Tommaso Cucinotta
2010-11-12 19:07             ` Raistlin
2010-11-13  0:43             ` Peter Zijlstra
2010-11-13  1:49               ` Tommaso Cucinotta
2010-11-12 18:56         ` Raistlin
     [not found]           ` <80992760-24F2-42AE-AF2D-15727F6A1C81@email.unc.edu>
2010-11-15 18:37             ` James H. Anderson [this message]
2010-11-15 19:23               ` Luca Abeni
2010-11-15 19:49                 ` James H. Anderson
2010-11-15 19:39               ` Luca Abeni
2010-11-15 21:34               ` Raistlin
2010-10-29  6:43 ` [RFC][PATCH 20/22] sched: drafted deadline inheritance logic Raistlin
2010-11-11 22:15   ` Peter Zijlstra
2010-11-14 12:00     ` Raistlin
2010-10-29  6:44 ` [RFC][PATCH 21/22] sched: add bandwidth management for sched_dl Raistlin
2010-10-29  6:45 ` [RFC][PATCH 22/22] sched: add sched_dl documentation Raistlin

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=4CE17DD2.3060807@cs.unc.edu \
    --to=anderson@cs.unc.edu \
    --cc=bbb@email.unc.edu \
    --cc=cfriesen@nortel.com \
    --cc=claudio@evidence.eu.com \
    --cc=cucinotta@sssup.it \
    --cc=darren@dvhart.com \
    --cc=dhaval@retis.sssup.it \
    --cc=fabio@gandalf.sssup.it \
    --cc=fweisbec@gmail.com \
    --cc=hgu1972@gmail.com \
    --cc=johan.eker@ericsson.com \
    --cc=juri.lelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.abeni@unitn.it \
    --cc=mingo@elte.hu \
    --cc=nicola.manica@disi.unitn.it \
    --cc=oleg@redhat.com \
    --cc=p.faure@akatech.ch \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=raistlin@linux.it \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=trimarchi@retis.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