[linux-audio-dev] another kernel patch?

[Paul Davis]

>> you end up with a truly superb architecture for the kind of thing
>> we're doing with JACK already.
>
>The new scheduler is very good at switching processes quickly.
>The old one had to walk throu all to decide which one to take,
>not the new one. So you will not save much by telling wich process to
>switch to. I think that the above figures include the scheduler!
>(Have to check)

the problem is not (just?) the time that the scheduler takes. its that
its decision making process is opaque. when jackd runs, it knows for
certain which pid/tid to run next. we don't want to cede control of
that back to the kernel scheduler. i think i've mentioned before that
i'd like to do a paper on JACK someday for Usenix, with a focus on its
capabilities for "user space cooperative real-time scheduling", or
something like that.

>> any thoughts? adding a syscall is a pretty trivial patch to create.
>
>And then the hard part begins - trying to get it accepted by Linus :-)

i've given up on that already. linus never accepted andrews lowlat
patch, and by all accounts the claims that 2.6 would meet the 2.4+LL
performance were overly optimistic. i thank god for mplayer/xine,
since the mainstream kernel developers now have somewhat realistic
streaming workloads to test the VM with. then there's the capabilities
issue, although the security modules stuff in 2.6 seems as if it might
address that. those of us who are serious about audio on linux may
just have to recognize that we need patched kernels for the best
results, which is actually OK from my perspective. it adds another
tiny crevice (i hesitate to call it a niche) for business models to
take advantage of.

--p