lkml.org 
[lkml]   [2014]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] sched/deadline: Add sched_dl documentation
    On 01/21/2014 01:33 PM, Peter Zijlstra wrote:
    > 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.
    Well, but it does happen in reality :)
    I mean: people might want to use SCHED_DEADLINE to schedule mplayer (or similar).
    There are even scientific papers showing the advantage of doing so...
    And if you try to use ftrace/kernelshark to check the wake-up times and similar
    you will notice that even a single-threaded player like mplayer blocks and wakes-up
    many times inside a job.

    On the other hand, I agree with you that a hard real-time task should be designed
    not to do things like this. But SCHED_DEADLINE is flexible enough to be used on
    many different kinds of tasks (hard real-time, soft real-time, etc...).

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

    > 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.
    Ok... My point was that it would be better (IMHO) to first explain how
    sched_deadline works (and no notion of job/instance, etc is needed for this),
    and then explain how this applies to the real-time task model (and here, of
    course all the formal notation can be introduced).

    Do you think this can be reasonable?

    > 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..
    Ok.
    I guess some of these details can be added incrementally, with additional
    patches?


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



    Thanks,
    Luca


    \
     
     \ /
      Last update: 2014-01-21 14:41    [W:2.374 / U:1.276 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site