24 Nov
2003
24 Nov
'03
11:50 p.m.
Kjetil Svalastog Matheussen <k.s.matheussen(a)notam02.no> writes:
> I couldn't wait til you found it, so I wrote
one from scratch instead. :)
> The url below point to a hackish patch againt 2.4.23-rc1, and yes, it is
> very simple. Works by setting /proc/sys/kernel/setschedandmlock to 1.
> http://www.notam02.no/arkiv/src/schedmlockpatch-2.4.23-rc1
Fernando Pablo Lopez-Lezcano <nando(a)ccrma.stanford.edu> writes:
Hey! Good! I'm very tempted to add it to the
Planet CCRMA kernels right
away :-)
Has it seen much testing? Not that something so simple would require a
lot of testing, of course. I'm trying to think of potential problems
(over the use of capabilities) and can't think of anything. The only
that would occur to me is that access to SCHED_FIFO would be more
universal whereas with capabilities, programs like givertcap or
jackstart are required.
I finally got around to testing Kjetil's patch (backported to 2.4.19).
It basically works, but I found a couple of problems...
(1) The patch allows SCHED_FIFO but not SCHED_RR. This makes
PortAudio V18 fail. That looks trivial to fix. Is there any reason
to allow one realtime scheduling policy and not the other?
(2) I can start `jackd -R' as a normal user, but its clients fail to
connect. This looks like a problem in the capabilities_workaround
logic of jack_start_thread(). The test fails because the engine has
the `realtime' flag set, but not `has_capabilities'. I hacked a
patch for that test and now it works. I need to figure out if that
is the correct fix before committing it to CVS, though.
I did this as a baseline before adding the `realtimegroup' logic we
discussed last week. I think I'll attempt that next, after fixing the
SCHED_RR omission.
--
joq