Re: [RFC][PATCH] Multimedia scheduling class

[Jussi Laako]

Peter Zijlstra wrote:
> This is typically the domain of soft-realtime, and as such would need a
> realtime scheduling class -- using a proportional class like you did
> just doesn't make sense for these tasks.

Yes, this is for a soft-realtime usage. Some of the tasks are
CPU-intensive while being realtime'ish, like video codecs and some audio
processing tasks. These audio processing tasks can have some amount of
buffering. The idea behind this patch is to make these tasks overlap
with the normal tasks while giving a slightly more responsive scheduling
behavior and to favor these multimedia tasks over others.

Another option would be to create another scheduler which could overlap
with the normal one, in a way FIFO/RR overlap. After inspecting current
scheduler code I thought that this kind of modification and use of the
same task tree would be feasible, instead of having it's own run queue.

> 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?

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


	- Jussi
--
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/