26 Apr
2005
26 Apr
'05
6:33 p.m.
The RT rlimits patch (nice-and-rt-prio-rlimits.patch) has been proposed
as a solution to allow audio users to run their applications with
realtime priorities. While more complicated to configure, it's a much
cleaner patch than realtime-lsm and it's likely to get merged soon _if_
enough audio users test it and confirm that it works.
To encourage this, I have created a wiki page containing installation
instructions, links to prebuilt PAM packages, etc:
http://www.steamballoon.com/wiki/Rlimits
If this works for you, I am collecting success reports. Please email
rlimits-success(a)steamballoon.com .
If you have any problems with it, LAU is probably the best place to ask
for help. Unfortunately I don't have large amounts of time to spend
helping people with this, so any help requests emailed to me directly
may be deleted without a reply. Sorry.
Thanks for testing!
Jody
26 Apr
26 Apr
8:14 p.m.
On Wed, Apr 27, 2005 at 06:32:32AM EST, Jody McIntyre wrote:
The RT rlimits patch (nice-and-rt-prio-rlimits.patch)
has been proposed
as a solution to allow audio users to run their applications with
realtime priorities. While more complicated to configure, it's a much
cleaner patch than realtime-lsm and it's likely to get merged soon _if_
enough audio users test it and confirm that it works.
To encourage this, I have created a wiki page containing installation
instructions, links to prebuilt PAM packages, etc:
http://www.steamballoon.com/wiki/Rlimits
Some distros, like Slackware do not use pam. How could this patch still
be used?
--
Luke Yelavich
http://www.audioslack.com
luke(a)audioslack.com
9:06 p.m.
On Wed, 2005-04-27 at 08:13 +1000, Luke Yelavich wrote:
On Wed, Apr 27, 2005 at 06:32:32AM EST, Jody McIntyre
wrote:
Well, how do you implement rlimits without PAM?
Lee
The RT rlimits patch
(nice-and-rt-prio-rlimits.patch) has been proposed
as a solution to allow audio users to run their applications with
realtime priorities. While more complicated to configure, it's a much
cleaner patch than realtime-lsm and it's likely to get merged soon _if_
enough audio users test it and confirm that it works.
To encourage this, I have created a wiki page containing installation
instructions, links to prebuilt PAM packages, etc:
http://www.steamballoon.com/wiki/Rlimits
Some distros, like Slackware do not use pam. How could this patch still
be used? 
10:17 p.m.
> On Wed, Apr 27, 2005 at 06:32:32AM EST, Jody
McIntyre wrote:
> > To encourage this, I have created a wiki page containing installation
> > instructions, links to prebuilt PAM packages, etc:
> > http://www.steamballoon.com/wiki/Rlimits
Thanks for providing clear instructions, Jody. This should help the
testing effort a lot.
On Wed, 2005-04-27 at 08:13 +1000, Luke Yelavich
wrote:
> Some distros, like Slackware do not use pam. How could this patch still
> be used?
Lee Revell <rlrevell(a)joe-job.com> writes:
Well, how do you implement rlimits without PAM?
You hack your favorite shell to recognize these new fields for the
`ulimit' command.
Man, those kernel guys sure are smart. It's no wonder Linux is so
easy to use. :-/
--
joq
27 Apr
27 Apr
7:17 p.m.
On Wed, Apr 27, 2005 at 09:06:16AM EST, Lee Revell wrote:
On Wed, 2005-04-27 at 08:13 +1000, Luke Yelavich
wrote:
If this question was directed at me, I don't know. I simply package
software for others to use on Slackware. Since Slackware doesn't have
Pam, I don't see how this patch would be useful, which will mean having
to use realtime-lsm.
--
Luke Yelavich
http://www.audioslack.com
luke(a)audioslack.com
On Wed, Apr 27, 2005 at 06:32:32AM EST, Jody
McIntyre wrote:
Well, how do you implement rlimits without PAM? The RT rlimits patch
(nice-and-rt-prio-rlimits.patch) has been proposed
as a solution to allow audio users to run their applications with
realtime priorities. While more complicated to configure, it's a much
cleaner patch than realtime-lsm and it's likely to get merged soon _if_
enough audio users test it and confirm that it works.
To encourage this, I have created a wiki page containing installation
instructions, links to prebuilt PAM packages, etc:
http://www.steamballoon.com/wiki/Rlimits
Some distros, like Slackware do not use pam. How could this patch still
be used?
1 May
1 May
11:51 p.m.
On Wed, Apr 27, 2005 at 08:13:21AM +1000, Luke Yelavich wrote:
Some distros, like Slackware do not use pam. How could
this patch still
be used?
Whatever deals with /etc/limits.conf will need to be patched. I can
probably come up with a patch if you can point me to the sources.
Jody
--
Luke Yelavich
http://www.audioslack.com
luke(a)audioslack.com
--
2 May
2 May
12:29 a.m.
On Mon, May 02, 2005 at 11:51:19AM EST, Jody McIntyre wrote:
On Wed, Apr 27, 2005 at 08:13:21AM +1000, Luke
Yelavich wrote:
limits.conf doesn't exist on any Slackware install I have here.
--
Luke Yelavich
http://www.audioslack.com
luke(a)audioslack.com
Some distros, like Slackware do not use pam. How
could this patch still
be used?
Whatever deals with /etc/limits.conf will need to be patched. I can
probably come up with a patch if you can point me to the sources. 
7 May
7 May
12:53 a.m.
New subject: [linux-audio-dev] Re: Please test the RT rlimits patch for audio
Jody McIntyre <scjody(a)modernduck.com>om>, on Sun May 01, 2005 [09:51:19 PM] said:
On Wed, Apr 27, 2005 at 08:13:21AM +1000, Luke
Yelavich wrote:
Hi;
I believe the program you would want to modify would be
the 'login' program. This can be provided by different
packages-- eg. if you use PAM, you will have a pam'ified login.
Slackware seems to use the login program provided by the shadow
package. (Actually, for people that dont care about PAM, a
modified login program might be a simpler solution-- I dont know
what the other ramifications of that might be offhand though;)
http://shadow.pld.org.pl/
The shadow login would use /etc/limits, which exists on the
slackware box I have access to. (there is a man page for limits(5))
Paul
set(a)pobox.com
ps. In theory is it possible to have a Gentoo system without PAM, in
which case the shadow packages login would also be used.
Some distros, like Slackware do not use pam. How
could this patch still
be used?
Whatever deals with /etc/limits.conf will need to be patched. I can
probably come up with a patch if you can point me to the sources.
Jody
27 Apr
27 Apr
1:01 p.m.
New subject: [linux-audio-dev] Re: Please test the RT rlimits patch for audio
|--==> Jody McIntyre writes:
JM> The RT rlimits patch (nice-and-rt-prio-rlimits.patch) has been proposed
JM> as a solution to allow audio users to run their applications with
JM> realtime priorities. While more complicated to configure, it's a much
JM> cleaner patch than realtime-lsm and it's likely to get merged soon _if_
JM> enough audio users test it and confirm that it works.
JM> To encourage this, I have created a wiki page containing installation
JM> instructions, links to prebuilt PAM packages, etc:
JM> http://www.steamballoon.com/wiki/Rlimits
JM> If this works for you, I am collecting success reports. Please email
JM> rlimits-success(a)steamballoon.com .
JM> If you have any problems with it, LAU is probably the best place to ask
JM> for help. Unfortunately I don't have large amounts of time to spend
JM> helping people with this, so any help requests emailed to me directly
JM> may be deleted without a reply. Sorry.
JM> Thanks for testing!
I'll provide a test debian package for the A/DeMuDi distribution. I'm
a bit busy ATM hope this will happen next week.
Cheers,
Free
28 Apr
28 Apr
1:16 p.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Please test the RT rlimits patch for audio
Jody McIntyre wrote:
The RT rlimits patch (nice-and-rt-prio-rlimits.patch)
has been proposed
as a solution to allow audio users to run their applications with
realtime priorities. While more complicated to configure, it's a much
cleaner patch than realtime-lsm and it's likely to get merged soon _if_
enough audio users test it and confirm that it works.
To encourage this, I have created a wiki page containing installation
instructions, links to prebuilt PAM packages, etc:
http://www.steamballoon.com/wiki/Rlimits
If this works for you, I am collecting success reports. Please email
rlimits-success(a)steamballoon.com .
If you have any problems with it, LAU is probably the best place to ask
for help. Unfortunately I don't have large amounts of time to spend
helping people with this, so any help requests emailed to me directly
may be deleted without a reply. Sorry.
i'd only compiled my first kernel the day before the post to LAU asking
people to test rlimits ... i had put realtime-lsm on top of that one ...
anyway, i got the 2.6.12RC2 kernel and patched that with the
nice/rlimits patch, then installed the patched PAM, edited limits.conf
with the settings suggested on the wiki, rebooted .... no realtime
access with jack :(
but then i changed the values in the limits.conf file to allow users of
"audio" group a rt_priority of 80, rather than the suggested 50 ...
logout/login - success!!!! (i think this could be because jack recently
changed its default RT priority to something like 63 ... i put 80 in
there just to be safe).
it seems to be pretty good, too - with my SB Live i can use a 256 period
setting with *no* troubles at all, running ardour/hydrogen/mixxx all at
the same time and fully loaded ... 128 works pretty well, too, with only
a few xruns (and no xruns if used in playback only mode).
i was using it all day yesterday at band practice, and it performed
admirably the whole way - not a single xrun, or performance issue :)
one thing i noticed is that whenever an audio app is started from the
terminal, it prints this out:
cannot lock down memory for RT thread (Cannot allocate memory)
though, in regards to what i mention above, this message doesn't seem to
have had an effect on performance ... what does it mean? surely jack at
least has RT access?!
anyway, all good it seems ... i'll update the wiki to mention about
trying a different value in the limits.conf file if things don't work.
shayne
1:53 p.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Please test the RT rlimits patch for audio
"Shayne O'Connor" <forums(a)machinehasnoagenda.com> writes:
one thing i noticed is that whenever an audio app is
started from the
terminal, it prints this out:
cannot lock down memory for RT thread (Cannot allocate memory)
though, in regards to what i mention above, this message doesn't seem to
have had an effect on performance ... what does it mean? surely jack at
least has RT access?!
The realtime-lsm grants memory locking privileges as well as
scheduling privileges. This is not essential, may systems will work
fine without it. But, if you are tight on memory, you may see rather
drastic xruns due to something getting paged out. Normally, the
realtime pages are "hot" enough to stay resident, anyway. That is why
JACK does not consider this a fatal error, even when running with -R.
If you are doing something critical (like recording a band), you
should probably also grant mlock() privileges. This is already
supported via rlimits in 2.6 kernels. Check it using the `ulimit -l'
command. The default limit is probably rather small.
Perhaps someone can explain how to do this using PAM. I believe you
set the `memlock' option in `/etc/security/limits.conf', somehow.
--
joq
2:36 p.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Please test the RT rlimits patch for audio
Jack O'Quin wrote:
"Shayne O'Connor"
<forums(a)machinehasnoagenda.com> writes:
yep, this works for me ... here are my PAM settings in limits.conf:
<domain> <type> <item> <value>
@audio - rt_priority 100
@audio - nice 10
@audio - memlock 250000
i've got a total of 512mb RAM, so i thought half of that would be
appropriate ... is this setting ok/too high/too low?
shayne
one thing i noticed is that whenever an audio app
is started from the
terminal, it prints this out:
cannot lock down memory for RT thread (Cannot allocate memory)
though, in regards to what i mention above, this message doesn't seem to
have had an effect on performance ... what does it mean? surely jack at
least has RT access?!
The realtime-lsm grants memory locking privileges as well as
scheduling privileges. This is not essential, may systems will work
fine without it. But, if you are tight on memory, you may see rather
drastic xruns due to something getting paged out. Normally, the
realtime pages are "hot" enough to stay resident, anyway. That is why
JACK does not consider this a fatal error, even when running with -R.
If you are doing something critical (like recording a band), you
should probably also grant mlock() privileges. This is already
supported via rlimits in 2.6 kernels. Check it using the `ulimit -l'
command. The default limit is probably rather small.
Perhaps someone can explain how to do this using PAM. I believe you
set the `memlock' option in `/etc/security/limits.conf', somehow.
4:07 p.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Please test the RT rlimits patch for audio
Jack O'Quin wrote:
>Perhaps someone can explain how to do this using PAM. I believe you
>set the `memlock' option in `/etc/security/limits.conf', somehow.
"Shayne O'Connor" <forums(a)machinehasnoagenda.com> writes:
yep, this works for me ... here are my PAM settings in
limits.conf:
<domain> <type> <item> <value>
@audio - rt_priority 100
@audio - nice 10
@audio - memlock 250000
i've got a total of 512mb RAM, so i thought half of that would be
appropriate ... is this setting ok/too high/too low?
Maybe. Depends on what JACK clients you run (they all get mlocked).
Ardour takes up quite a lot of space. If you're willing to grant the
max priority (100), your system is probably a dedicated audio
workstation, so you might just as well make memlock "unlimited".
There is also the -m (--no-mlock) JACK option that disables memory
locking even with the -R (--realtime) option.
--
joq
1 May
1 May
11:50 p.m.
I updated the PAM patch and packages on Friday to fix a couple of
issues:
- By default, non-audio users had _unlimited_ realtime and nice
privileges. They are now restricted to 0 and 0, as before the patch.
- Nice values in limits.conf now follow standard nice ranges: -20 to 19.
If you have already installed the packages, I suggest you at least
update limits.conf.
Jody
22 May
22 May
3:27 a.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Please test the RT rlimits patch for audio
On Tue, 2005-04-26 at 16:32 -0400, Jody McIntyre wrote:
It appears that Linux has merged the RT rlimit patch, as of 2.6.12-rc3
or -rc4. I updated the wiki to remove the extra step of patching the
kernel.
Lee
4:11 a.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Please test the RT rlimits patch for audio
On Tue, 2005-04-26 at 16:32 -0400, Jody McIntyre wrote:
The RT rlimits patch (nice-and-rt-prio-rlimits.patch)
has been
proposed
as a solution to allow audio users to run their applications with
realtime priorities. While more complicated to configure, it's a much
cleaner patch than realtime-lsm and it's likely to get merged soon
_if_
enough audio users test it and confirm that it works.
For any Ubuntu users that are interested, I made a feature request here:
https://bugzilla.ubuntu.com/show_bug.cgi?id=11059
Lee
7154
days inactive
7180
days old
linux-audio-dev@lists.linuxaudio.org
15 comments
7 participants
participants (7)
-
Free Ekanayaka -
Jack O'Quin -
Jody McIntyre -
Lee Revell -
Luke Yelavich -
Paul -
Shayne O'Connor