All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Luca Abeni <luca.abeni@unitn.it>
Cc: Henrik Austad <henrik@austad.us>,
	Juri Lelli <juri.lelli@gmail.com>,
	tglx@linutronix.de, mingo@redhat.com, rostedt@goodmis.org,
	oleg@redhat.com, fweisbec@gmail.com, darren@dvhart.com,
	johan.eker@ericsson.com, p.faure@akatech.ch,
	linux-kernel@vger.kernel.org, claudio@evidence.eu.com,
	michael@amarulasolutions.com, fchecconi@gmail.com,
	tommaso.cucinotta@sssup.it, nicola.manica@disi.unitn.it,
	dhaval.giani@gmail.com, hgu1972@gmail.com,
	paulmck@linux.vnet.ibm.com, raistlin@linux.it,
	insop.song@gmail.com, liming.wang@windriver.com,
	jkacur@redhat.com, harald.gustafsson@ericsson.com,
	vincent.guittot@linaro.org, bruce.ashfield@windriver.com,
	rob@landley.net
Subject: Re: [PATCH] sched/deadline: Add sched_dl documentation
Date: Tue, 21 Jan 2014 13:33:34 +0100	[thread overview]
Message-ID: <20140121123334.GJ30183@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <52DE5B7F.8020900@unitn.it>

On Tue, Jan 21, 2014 at 12:35:27PM +0100, Luca Abeni wrote:
> >In a system, we typically look at a set of tasks. In Linux-kernel
> >terminology, a particular task is normally a thread. When a thread is
> >ready to run, we say that a *job* of that task is running.
> This would be true in the original Liu&Layland model (where a task blocks
> only when a job finishes), but I do not think it is correct in a real system...
> For example: (notice: this discussion might be slightly off-topic, and I do not
> think this should go in the document... I am writing just to clarify my point
> of view)
> - Let's consider a (over simplified) video decoder as an example of task
> - The task periodically read a video frame (from disk or network), decodes it,
>   and displays it
> - So, each job starts when the frame is read, and finishes when the frame is
>   displayed. And jobs are (in this case) activated periodically
> - During the execution of a job, the task might invoke a blocking system call,
>   and block... When it wakes up, it is still in the same job (decoding the same
>   video frame), and not in a different one.
> This is (IMHO) where all the confusion comes from.

I would strongly urge you not to use that as an example, because its
dead wrong design. An RT thread (be it RR,FIFO or DL) should _NEVER_ do
blocking IO.

Have !RT tasks read the stuff from disk into a buffer, then let the RT
task read data from the buffer and flip frames and such.

If you want to mention blocking, then please use the most common one:
blocking on a (hopefully PI) mutex.



On the other subject; I wouldn't actually mind if it grew into a proper
(academic or not) summary of deadline scheduling theory and how it
applies.

Sure, refer to actual papers for all the proofs and such, but it would
be very good to go over all the bits and pieces that make up the system.

So cover the periodic, sporadic and aperiodic model like henr_k
suggested, please do cover the job/instance idiom as it is used all over
the place.

Then also treat schedulability tests and their ramification, explain
what laxity is, what tardiness is, that GEDF doesn't have 0 tardiness
but does have bounded tardiness.

Maybe even mention the actual bounds -- but refer to papers for their
proofs.

Mention CBS and the ramification etc..


Yes this is all a bit much, but I feel it is important, after all how
can you properly use something you don't understand? (and yes I know its
a very popular thing to not want to understand how things work but still
use them :-/).

I mean, I'm the kind of idiot that actually goes out and read a bunch of
papers, but many people simply cannot read those things, or are not
given the time to, even if they wanted and could (arguably they have
bigger problems).

so think of this as the idiot guide to deadline scheduling :-)

  parent reply	other threads:[~2014-01-21 12:34 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-20 10:40 [PATCH] sched/deadline: Add sched_dl documentation Juri Lelli
2014-01-20 11:24 ` Henrik Austad
2014-01-20 11:46   ` Peter Zijlstra
2014-01-21 14:55     ` Steven Rostedt
2014-01-20 12:15   ` Juri Lelli
2014-01-20 13:16     ` Henrik Austad
2014-01-20 13:39       ` Luca Abeni
2014-01-21 10:20         ` Henrik Austad
2014-01-21 11:35           ` Luca Abeni
2014-01-21 12:11             ` Juri Lelli
2014-01-21 12:33             ` Peter Zijlstra [this message]
2014-01-21 12:50               ` Luca Abeni
2014-01-21 13:55                 ` Peter Zijlstra
2014-01-21 14:38                   ` Juri Lelli
2014-01-21 16:28                   ` Steven Rostedt
2014-01-22 13:03                   ` Luca Abeni
2014-01-22 13:51                     ` Peter Zijlstra
2014-01-24 10:08                       ` Tommaso Cucinotta
2014-01-28  9:31                         ` Peter Zijlstra
2014-01-28 18:22                           ` Tommaso Cucinotta
2014-01-21 10:21   ` Henrik Austad
2014-01-20 12:25 ` Luca Abeni
  -- strict thread matches above, loose matches on Subject: below --
2014-01-27 11:20 Juri Lelli
2014-01-27 11:23 ` Juri Lelli
2014-01-27 11:53 ` Henrik Austad
2014-01-27 12:30   ` Luca Abeni
2014-01-27 12:40     ` Henrik Austad
2014-01-27 12:52       ` Luca Abeni
2014-01-27 15:35 ` Steven Rostedt
2014-01-27 16:56   ` Luca Abeni
2014-01-27 17:09     ` Steven Rostedt
2014-01-27 22:29       ` Luca Abeni
2014-01-28 10:03         ` Juri Lelli

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=20140121123334.GJ30183@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bruce.ashfield@windriver.com \
    --cc=claudio@evidence.eu.com \
    --cc=darren@dvhart.com \
    --cc=dhaval.giani@gmail.com \
    --cc=fchecconi@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=harald.gustafsson@ericsson.com \
    --cc=henrik@austad.us \
    --cc=hgu1972@gmail.com \
    --cc=insop.song@gmail.com \
    --cc=jkacur@redhat.com \
    --cc=johan.eker@ericsson.com \
    --cc=juri.lelli@gmail.com \
    --cc=liming.wang@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.abeni@unitn.it \
    --cc=michael@amarulasolutions.com \
    --cc=mingo@redhat.com \
    --cc=nicola.manica@disi.unitn.it \
    --cc=oleg@redhat.com \
    --cc=p.faure@akatech.ch \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=raistlin@linux.it \
    --cc=rob@landley.net \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tommaso.cucinotta@sssup.it \
    --cc=vincent.guittot@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.