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

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

Con Kolivas <kernel@kolivas.org> writes:

> Jack O'Quin wrote:
>> Try again with JACK 0.99.48.  It's in CVS now, but you probably need
>> this tarball to get around the dreaded SourceForge anon CVS lag...
>>
>> http://www.joq.us/jack/tarballs/jack-audio-connection-kit-0.99.48.tar.gz
>
> Thanks it finally ran to completion. By the way the patch you sent
> with the test suite did not apply so I had to do it manually
> (booraroom..)

Oops!  Sorry.  I generated those by hand using some rather crude 
`diff -u .... >> xxx.diff' commands.  

We should just add Rui's latest version to JACK CVS.

> Since I (finally) have it running at this end at last I'll do some
> benchmarking of my own to see how (lack of) priorities affects
> SCHED_ISO. If it is inadequate, it wont be too difficult to add them
> to the design. The problem with priorities is that once you go over
> the cpu limit everyone suffers equally; but that's a failsafe that you
> shouldn't actually hit in normal usage so it probably doesn't
> matter... 

I'd be surprised if we're hitting it in this test.  AFAICT, our
"Average DSP Load" should approximate your CPU limit.  That's running
in the 30% to 40% range.  Is there any way to verify this?  Is your
running average readable in /proc/sys/kernel somewhere?

We do need to test that the system degrades gracefully when the CPU is
overloaded.  That *will* happen (the dreaded P4 float denormal
problems quickly come to mind).  At some point, the user should be
allowed to choose how much CPU to consume, possibly shutting down
plugins as needed.

> Hmm come to think of it, it probably _is_ a good idea to implement
> priority support afterall.

Hard to say for sure without trying it.  These threads are dealing
with a realtime cycle that is smaller than normal scheduler time
slices.  Getting all the work done is important.  But, getting it done
in the right order might make a difference for important statistics
like Max Delay.
-- 
  joq