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