Audio latency - resource limits win [LWN.net]

The long debate on how to provide preferential scheduling for audio applications would appear to have come to an end. The realtime Linux security module has not been merged; instead, the mainline now includes a version of the rlimit patch. This is not the outcome which was most favored by the audio development community, but it will still be useful for them.

The patch creates two new resource limits. RLIMIT_NICE controls the maximum "niceness" that the process can set for itself in the normal timesharing scheduler. The limit has a range of 0..39, with 39 corresponding to an internal niceness value of -20 - the highest priority. The difference between the resource limit value and the actual niceness values may seem confusing, but apparently it's unavoidable: the Single Unix Standard specifies that resource limits must be unsigned values.

The other limit is RLIMIT_RTPRIO; it can have a range of 0..100. If it is nonzero, the process is empowered to use the realtime scheduling classes up to the indicated priority.

The problem with this approach, from the point of view of the audio community, is that it is not currently supported by any distribution. It is easy to set up PAM to give expanded limits to specific users or groups - once PAM has been patched to understand the new limits. Shells, too, must be patched before their ulimit commands can be used to change the limits. So it will be some time before an "out of the box" Linux system will be able to take advantage of this new capability.

In the long term, however, the rlimit patch looks like a minimally invasive way of making realtime scheduling available, in a relatively safe way, to ordinary users. Anybody wanting to play with the new mechanism before their distribution catches up can find instructions and patches on this web page.

Index entries for this article
Kernel	Latency

to post comments

Value range

Posted May 5, 2005 7:52 UTC (Thu) by Ross (guest, #4065) [Link] (2 responses)

The values could at least match the name: smaller values should be less
nice and larger values more nice. Or maybe they should name the resource
"notnice" :)

Value range

Posted May 5, 2005 21:28 UTC (Thu) by phiggins (guest, #5605) [Link] (1 responses)

I was thinking the same thing at first, but since we are talking about a limit, it makes more sense to have increasing privilege correspond to an increasing limit. That way it's more like all the other limits. It's really the negative values for nice that are weird.

Value range

Posted May 6, 2005 23:48 UTC (Fri) by giraffedata (guest, #1954) [Link]

You're both right. The name should be RLIMIT_MEAN. A limit on how mean you can be.

I don't know anything about the early history of nice, but I suspect the negative values were an add-on. I think someone setting out to design a general CPU share setting wouldn't do it that way.