Re: [RFC][PATCH] Multimedia scheduling class

[Peter Zijlstra]

Right, so I totally lost this thread in my inbox -- sorry for that.

On Tue, 2008-12-30 at 10:39 +0200, Jussi Laako wrote:

> > Eventually we'd hope to provide an sporadic task EDF based scheduler
> > with hard and soft realtime capabilities, but until that time, FIFO and
> > RR are the classes to use for anything realtime.
> 
> Yes, this is also what I thought first and I still believe this would
> also be a good addition. After a bit more thinking I concluded that it
> might be a bit too hard-realtime'ish for many of the tasks. It would
> become rather close to running FIFO with flat priority?

Not quite so, you can avoid starvation with deadline schedulers, just
limit their budget.

> ....and these tasks are not sporadic, but strictly periodic...
> 
> > I'm not sure why you think SCHED_FIFO isn't good enough for your
> > applications, could you elaborate on that?
> 
> Actually the biggest problem is that many of the developers are not
> comfortable with using SCHED_FIFO for the purpose... :)

Well, that's not my problem is it ;-), just batter them with a
clue-stick, no need to fudge the kernel for that.

> FIFO is unsuitable for video codecs, RR would be better there, but still
> it would starve rest of the system too much in some cases (it can lose
> some frames to keep rest of the system responsive).

Right, which is where deadline scheduling would be nice. Once you start
running into the budget throttle you know you've got to start dropping
frames in order to keep up.

The proposal is for it to start sending SIGXCPU once it starts
throttling tasks in order to notify them of missed deadlines etc.

> Some multimedia software is just not implemented in a way that it would
> be safe to run these at RT-priority (having various too
> nondeterministic code paths).

Like said, deadline schedulers can help here. You can even dynamically
adjust the parameters -- eg. fall back to half frame rate but double
budget or something.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/