Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

["Jack O'Quin" <joq@io.com>]

Ingo Molnar <mingo@elte.hu> writes:

> * Jack O'Quin <joq@io.com> wrote:
>
>>   First, only SCHED_FIFO worked reliably in my tests.  In Con's tests
>>   even that did not work.  My system is probably better tuned for low
>>   latency than his.  Until we can determine why there were so many
>>   xruns, it is premature to declare victory for either scheduler.
>>   Preferably, we should compare them on a well-tuned low-latency
>>   system running your Realtime Preemption kernel.
>
> i didnt declare victory - the full range of latency fixes is in the -RT
> tree. Merging of relevant bits is an ongoing process - in 2.6.10 you've
> already seen some early results, but it's by no means complete. 

I didn't mean to insult you, Ingo.  

I have nothing but praise for what you've accomplished with 2.6.10.
My tests yesterday demonstrated slightly better SCHED_FIFO performance
with 2.6.10 than 2.4.19 with Andrew's low-latency patches.  For a
mainstream kernel that is a huge accomplishment, never before
achieved.  We should celebrate.

I was just pointing out that saying nice(-20) works as well as
SCHED_ISO, though true, doesn't mean much since neither of them
(currently) work well enough to be useful.

>>   Second, the nice(-20) scheduler provides no clear way to support
>>   multiple realtime priorities. [...]
>
> why? You could use e.g. nice -20, -19 and -18. (see the patch below that
> implements this.)

Which of the the POSIX 1-99 range do you map into those three
priorities?  (I can't figure it out from the patch.)

How does one go about deciding which priority differences "matter" and
which do not?  Why not honor the realtime programmer's choice of
priorities?

For good reasons, most audio developers prefer the POSIX realtime
interfaces.  They are far from perfect, but remain the only workable,
portable solution available.  That is why I like your rt_cpu_limit
proposal so much better that this one.
-- 
  joq