Messages in this thread | | | Date | Tue, 21 Jan 2014 13:50:41 +0100 | From | Luca Abeni <> | Subject | Re: [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
| |