Re: [PATCH] [request for inclusion] Realtime LSM

Jack O'Quin
2005-01-15T23:38:22Z

>> * Jack O'Quin <joq@io.com> wrote:
>>> One major problem: this `nice --20' hack affects every thread, not
>>> just the critical realtime ones. That's not what we want. Audio
>>> applications make very conscious choices which threads run with high
>>> priority and which do not.

> Ingo Molnar <mingo@elte.hu> writes:
>> how much did this problem affect your test? Could the source of the 500
>> msec delays be the non-highprio components of the test that somehow
>> became nice --20?

Jack O'Quin <joq@io.com> writes:
> Probably, the best way to tell would be patching JACK so it uses
> nice(-20) instead of pthread_setschedparam() for the realtime threads.
> As a hack, that looks easy. I'll build a working directory with just
> that change, so we can experiment with it better.

Bah! Nothing is ever as easy as it looks.

According to the manpage, nice(2) is per-process not per-thread. That
does not give the granularity we need.

Is that correct? If so, I can't think of any way to make this work.
Suggestions?

We need to allow both realtime and non-realtime threads in the same
process. Anything less would require an enormous rewrite for most
audio programs, an unreasonable thing to ask.
--
joq