20 Nov
2010
20 Nov
'10
10:48 a.m.
Hi
Aparently a new, 200 lines kernel patch have been buzzing the web
lately, supposedly it should provide a much more responsive desktop.
But this userspace alternative should be even better:
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
Anyone heard of it, tried it and/or has any thoughts whether it has
anything to offer on a DAW?
--
Atte
http://atte.dk http://modlys.dk
20 Nov
20 Nov
2:26 p.m.
On Sat, Nov 20, 2010 at 4:48 AM, Atte André Jensen <atte(a)email.dk> wrote:
Hi
Aparently a new, 200 lines kernel patch have been buzzing the web lately,
supposedly it should provide a much more responsive desktop.
But this userspace alternative should be even better:
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
Anyone heard of it, tried it and/or has any thoughts whether it has anything
to offer on a DAW?
it doesn't look terribly relevant because a DAW is going to schedule
most threads that matter with SCHED_FIFO. these threads will be
scheduled by a different set of rules than SCHED_OTHER (i.e. most of
the desktop threads, and the scheduling class that is affected by the
patch). that's not to say it might not still make things feel a bit
better, but it won't really make lower latencies possible etc. etc.. I
think.
7:33 p.m.
On Sat, Nov 20, 2010 at 08:26:45AM -0500, Paul Davis wrote:
On Sat, Nov 20, 2010 at 4:48 AM, Atte André Jensen
<atte(a)email.dk> wrote:
looking at the 200lines patch... it seems to activate RT_GROUP_SCHED
if anybody know how the system needs to be configured, so that jackd
runs with this option on, it might be nice if you told us.
if we really get kernels with this turned on soon, we better be prepared.
Hi
Aparently a new, 200 lines kernel patch have been buzzing the web lately,
supposedly it should provide a much more responsive desktop.
But this userspace alternative should be even better:
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
Anyone heard of it, tried it and/or has any thoughts whether it has anything
to offer on a DAW?
it doesn't look terribly relevant because a DAW is going to schedule
most threads that matter with SCHED_FIFO. these threads will be
scheduled by a different set of rules than SCHED_OTHER (i.e. most of
the desktop threads, and the scheduling class that is affected by the
patch). that's not to say it might not still make things feel a bit
better, but it won't really make lower latencies possible etc. etc.. I
think. _______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
torben Hohn
7:38 p.m.
On 21 November 2010 02:33, torbenh <torbenh(a)gmx.de> wrote:
On Sat, Nov 20, 2010 at 08:26:45AM -0500, Paul Davis
wrote:
In fact, isn't cgroups incompatible with realtime scheduling? Not
quite sure where I'm quoting that from but I vaguely recall something
like that.
--
GPG/PGP ID: B42DDCAD
On Sat, Nov 20, 2010 at 4:48 AM, Atte André
Jensen <atte(a)email.dk> wrote:
looking at the 200lines patch... it seems to activate RT_GROUP_SCHED
if anybody know how the system needs to be configured, so that jackd
runs with this option on, it might be nice if you told us.
if we really get kernels with this turned on soon, we better be prepared. Hi
Aparently a new, 200 lines kernel patch have been buzzing the web lately,
supposedly it should provide a much more responsive desktop.
But this userspace alternative should be even better:
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
Anyone heard of it, tried it and/or has any thoughts whether it has anything
to offer on a DAW?
it doesn't look terribly relevant because a DAW is going to schedule
most threads that matter with SCHED_FIFO. these threads will be
scheduled by a different set of rules than SCHED_OTHER (i.e. most of
the desktop threads, and the scheduling class that is affected by the
patch). that's not to say it might not still make things feel a bit
better, but it won't really make lower latencies possible etc. etc.. I
think. 
7:57 p.m.
Ray Rashif wrote:
On 21 November 2010 02:33, torbenh
<torbenh(a)gmx.de> wrote:
According to extended discussion of this on Slashdot yesterday, the
kernel patch and the alternative listed are essentially the same: the
alternative is what they were using in testing to decide what to put
into the kernel patch. Kernel developers decided that the patch was the
better way to do it. It uses a feature that's been in the kernel for a
couple of years now.
No info about impact on RT scheduling that I saw mentioned anywhere in
the discussion.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
On Sat, Nov 20, 2010 at 08:26:45AM -0500, Paul
Davis wrote:
In fact, isn't cgroups incompatible with realtime scheduling? Not
quite sure where I'm quoting that from but I vaguely recall something
like that. On Sat, Nov 20, 2010 at 4:48 AM, Atte André
Jensen <atte(a)email.dk> wrote:
looking at the 200lines patch... it seems to activate RT_GROUP_SCHED
if anybody know how the system needs to be configured, so that jackd
runs with this option on, it might be nice if you told us.
if we really get kernels with this turned on soon, we better be prepared. Hi
Aparently a new, 200 lines kernel patch have been buzzing the web lately,
supposedly it should provide a much more responsive desktop.
But this userspace alternative should be even better:
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
Anyone heard of it, tried it and/or has any thoughts whether it has anything
to offer on a DAW?
it doesn't look terribly relevant because a DAW is going to
schedule
most threads that matter with SCHED_FIFO. these threads will be
scheduled by a different set of rules than SCHED_OTHER (i.e. most of
the desktop threads, and the scheduling class that is affected by the
patch). that's not to say it might not still make things feel a bit
better, but it won't really make lower latencies possible etc. etc.. I
think. 
21 Nov
21 Nov
11:15 a.m.
Excerpts from david's message of 2010-11-20 19:57:45 +0100:
Ray Rashif wrote:
Sounds like slashdot rephrased the lkml discussion :)
The whole thing needs cgroups enabled, is this a good idea at all?
On 21 November 2010 02:33, torbenh
<torbenh(a)gmx.de> wrote:
According to extended discussion of this on Slashdot yesterday, the
kernel patch and the alternative listed are essentially the same: the
alternative is what they were using in testing to decide what to put
into the kernel patch. Kernel developers decided that the patch was the
better way to do it. It uses a feature that's been in the kernel for a
couple of years now.
No info about impact on RT scheduling that I saw mentioned anywhere in
the discussion. On Sat, Nov 20, 2010 at 08:26:45AM -0500, Paul
Davis wrote:
In fact, isn't cgroups incompatible with realtime scheduling? Not
quite sure where I'm quoting that from but I vaguely recall something
like that. On Sat, Nov 20, 2010 at 4:48 AM, Atte André
Jensen <atte(a)email.dk> wrote:
> Hi
>
> Aparently a new, 200 lines kernel patch have been buzzing the web lately,
> supposedly it should provide a much more responsive desktop.
>
> But this userspace alternative should be even better:
> http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
>
> Anyone heard of it, tried it and/or has any thoughts whether it has anything
> to offer on a DAW?
it doesn't look terribly relevant because a DAW is going to schedule
most threads that matter with SCHED_FIFO. these threads will be
scheduled by a different set of rules than SCHED_OTHER (i.e. most of
the desktop threads, and the scheduling class that is affected by the
patch). that's not to say it might not still make things feel a bit
better, but it won't really make lower latencies possible etc. etc.. I
think.
looking at the 200lines patch... it seems to activate RT_GROUP_SCHED
if anybody know how the system needs to be configured, so that jackd
runs with this option on, it might be nice if you told us.
if we really get kernels with this turned on soon, we better be prepared.
22 Nov
22 Nov
4:54 a.m.
Philipp Überbacher wrote:
Excerpts from david's message of 2010-11-20
19:57:45 +0100:
Basically, with additional confusions introduced by people who hadn't
participated in the lkml discussion. Some of the Slashdot folk had been
in the lkml discussion, so last I looked, most people were ok.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
Ray Rashif wrote:
Sounds like slashdot rephrased the lkml discussion :) On 21 November 2010 02:33, torbenh
<torbenh(a)gmx.de> wrote:
According to extended discussion of this on Slashdot yesterday, the
kernel patch and the alternative listed are essentially the same: the
alternative is what they were using in testing to decide what to put
into the kernel patch. Kernel developers decided that the patch was the
better way to do it. It uses a feature that's been in the kernel for a
couple of years now.
No info about impact on RT scheduling that I saw mentioned anywhere in
the discussion. On Sat, Nov 20, 2010 at 08:26:45AM -0500, Paul
Davis wrote:
> On Sat, Nov 20, 2010 at 4:48 AM, Atte André Jensen <atte(a)email.dk> wrote:
>> Hi
>>
>> Aparently a new, 200 lines kernel patch have been buzzing the web lately,
>> supposedly it should provide a much more responsive desktop.
>>
>> But this userspace alternative should be even better:
>> http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
>>
>> Anyone heard of it, tried it and/or has any thoughts whether it has anything
>> to offer on a DAW?
> it doesn't look terribly relevant because a DAW is going to schedule
> most threads that matter with SCHED_FIFO. these threads will be
> scheduled by a different set of rules than SCHED_OTHER (i.e. most of
> the desktop threads, and the scheduling class that is affected by the
> patch). that's not to say it might not still make things feel a bit
> better, but it won't really make lower latencies possible etc. etc.. I
> think.
looking at the 200lines patch... it seems to activate RT_GROUP_SCHED
if anybody know how the system needs to be configured, so that jackd
runs with this option on, it might be nice if you told us.
if we really get kernels with this turned on soon, we better be prepared.
In fact,
isn't cgroups incompatible with realtime scheduling? Not
quite sure where I'm quoting that from but I vaguely recall something
like that.
20 Nov
20 Nov
8:01 p.m.
On Sat, Nov 20, 2010 at 1:38 PM, Ray Rashif <schivmeister(a)gmail.com> wrote:
In fact, isn't cgroups incompatible with realtime
scheduling? Not
quite sure where I'm quoting that from but I vaguely recall something
like that.
its not incompatible with it. but you do have to create a cgroup and
allow SCHED_FIFO to be used within the group. the whole PAM thing
doesn't take care of this.
21 Nov
21 Nov
1:44 p.m.
On 11/20/10 20:38, Ray Rashif wrote:
On 21 November 2010 02:33, torbenh
<torbenh(a)gmx.de> wrote:
Cgroups (using the 'Ubuntu'-style workaround mentioned in the original article)
+ realtime scheduling works here, on Gentoo, kernel 2.6.34-r12, but needs a
little extra configuration in /etc/security/limits.d/audio.conf, please see here
http://en.gentoo-wiki.com/wiki/JACK#Kernel_Configuration
JR
--
| me@home ~$whoami ^ ^ | "Trust me, I know what I'm doing!" |
| Jouni 'Mad Max' Rinne ('x') | - Sledge Hammer |
| me@home ~$man woman C " " | -------[ph34r t3h p3Ngu1n]-------- |
| Segmentation fault (core dumped) | :: Last.fm user ID: l33tmmx :: |
On Sat, Nov 20, 2010 at 08:26:45AM -0500, Paul
Davis wrote:
In fact, isn't cgroups incompatible with realtime scheduling? Not
quite sure where I'm quoting that from but I vaguely recall something
like that. On Sat, Nov 20, 2010 at 4:48 AM, Atte André
Jensen <atte(a)email.dk> wrote:
looking at the 200lines patch... it seems to activate RT_GROUP_SCHED
if anybody know how the system needs to be configured, so that jackd
runs with this option on, it might be nice if you told us.
if we really get kernels with this turned on soon, we better be prepared. Hi
Aparently a new, 200 lines kernel patch have been buzzing the web lately,
supposedly it should provide a much more responsive desktop.
But this userspace alternative should be even better:
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
Anyone heard of it, tried it and/or has any thoughts whether it has anything
to offer on a DAW?
it doesn't look terribly relevant because a DAW is going to schedule
most threads that matter with SCHED_FIFO. these threads will be
scheduled by a different set of rules than SCHED_OTHER (i.e. most of
the desktop threads, and the scheduling class that is affected by the
patch). that's not to say it might not still make things feel a bit
better, but it won't really make lower latencies possible etc. etc.. I
think.
2:43 p.m.
On Sun, Nov 21, 2010 at 7:43 AM, Jouni Rinne <l33tmmx(a)gmail.com> wrote:
Cgroups (using the 'Ubuntu'-style workaround
mentioned in the original article)
+ realtime scheduling works here, on Gentoo, kernel 2.6.34-r12, but needs a
little extra configuration in /etc/security/limits.d/audio.conf, please see here
http://en.gentoo-wiki.com/wiki/JACK#Kernel_Configuration
the information contained on this page is at best misleading, and
arguably wrong.
22 Nov
22 Nov
11:14 a.m.
On 2010-11-21 14:43, Paul Davis wrote:
the information contained on this page is at best
misleading, and
arguably wrong.
Thanks everyone for the inputs. I think I'll wait a bit with the cgroups
stuff...
--
Atte
http://atte.dk http://modlys.dk
2:20 p.m.
On Mon, Nov 22, 2010 at 11:14:50AM +0100, Atte André Jensen wrote:
On 2010-11-21 14:43, Paul Davis wrote:
the third version of the patch didnt turn RT_GROUP_SCHED on.
we wont have problems with that version of the patch.
sorry for the noise.
thats what one gets if he doesnt read lkml :S
--
torben Hohn
the information contained on this page is at best
misleading, and
arguably wrong.
Thanks everyone for the inputs. I think I'll wait a bit with the
cgroups stuff... 
7:21 p.m.
On Mon, Nov 22, 2010 at 8:20 AM, torbenh <torbenh(a)gmx.de> wrote:
the third version of the patch didnt turn
RT_GROUP_SCHED on.
we wont have problems with that version of the patch.
sorry for the noise.
thats what one gets if he doesnt read lkml :S
Has lwn.net weighed in on this? Or does anyone here know if they will soon?
I'm not used to seeing press releases about kernel patches. I was half
expecting to see it on snopes.
--
Darrin
10:56 p.m.
On Mon, Nov 22, 2010 at 6:21 PM, Darrin Thompson <darrinth(a)gmail.com> wrote:
Has lwn.net weighed in on this? Or does anyone here
know if they will soon?
http://lwn.net/SubscriberLink/415740/54028f24b103f4ff/
From last Wednesday -- i.e. this predates the Slashdot
posting and
presumably some actual development.
Chris
24 Nov
24 Nov
7:55 a.m.
http://lwn.net/SubscriberLink/415740/54028f24b103f4ff/
...............................
"Most outspoken - as he often is - is Lennart Poettering, who asserted
that "Binding something like this to TTYs is just backwards"; he would
rather see something which is based on sessions. And, he said, all of
this could better be done in user space. Linus was, to put it
politely, unimpressed, but Lennart came back with a few lines of bash
scripting which achieves the same result as Mike's patch - with no
kernel patching required at all. It turns out that working with
control groups is not necessarily that hard."
................................
Have these people arguing against Lennart ever heard of GUI apps? And
what exactly is the "TTY" of an application "in the cloud." And how
exactly would keying off the tty be used in a paravirtualized kernel?
For example, many GUI based programs run out of pty's by running
subprocesses or networked subprocesses. This includes applications
based on libexpect(3), Qt apps using QProcess, or emacs subprocesses.
How would this silly kernel-bloating hack work with such programs?
So IMHO, this is design based on the flawed logic of "If the only tool
you have is a terminal emulator everything begins to look like a text
based program"
Lennart agrees:
http://lwn.net/Articles/415756/
...............
"Well, this feature is pretty much interesting only for kernel hackers
anyway. It is completely irrelevant for normal desktop people. Because
a) normal users don't use many terminals anyway and that very seldom and
b) if they do that they do not create gazillion of processes from one of
the terminals and only very few in the other. Because only then this
patch becomes relevant.
Heck, the patch wouldn't even have any effect on my machine (and I am
hacker), because I tend to run my builds from within emacs. And since
emacs has no TTY (since it is a X11/gtk build) it wouldn't be in its own
scheduling group."
.....................
-- Niels
http://nielsmayer.com
10:20 a.m.
Excerpts from Niels Mayer's message of 2010-11-24 07:55:46 +0100:
http://lwn.net/SubscriberLink/415740/54028f24b103f4ff/
...............................
"Most outspoken - as he often is - is Lennart Poettering, who asserted
that "Binding something like this to TTYs is just backwards"; he would
rather see something which is based on sessions. And, he said, all of
this could better be done in user space. Linus was, to put it
politely, unimpressed, but Lennart came back with a few lines of bash
scripting which achieves the same result as Mike's patch - with no
kernel patching required at all. It turns out that working with
control groups is not necessarily that hard."
................................
Have these people arguing against Lennart ever heard of GUI apps? And
what exactly is the "TTY" of an application "in the cloud." And how
exactly would keying off the tty be used in a paravirtualized kernel?
For example, many GUI based programs run out of pty's by running
subprocesses or networked subprocesses. This includes applications
based on libexpect(3), Qt apps using QProcess, or emacs subprocesses.
How would this silly kernel-bloating hack work with such programs?
So IMHO, this is design based on the flawed logic of "If the only tool
you have is a terminal emulator everything begins to look like a text
based program"
Lennart agrees:
http://lwn.net/Articles/415756/
...............
"Well, this feature is pretty much interesting only for kernel hackers
anyway. It is completely irrelevant for normal desktop people. Because
a) normal users don't use many terminals anyway and that very seldom and
b) if they do that they do not create gazillion of processes from one of
the terminals and only very few in the other. Because only then this
patch becomes relevant.
Heck, the patch wouldn't even have any effect on my machine (and I am
hacker), because I tend to run my builds from within emacs. And since
emacs has no TTY (since it is a X11/gtk build) it wouldn't be in its own
scheduling group."
.....................
-- Niels
http://nielsmayer.com
I recommend reading the original discussion on lkml
22 Nov
22 Nov
9:41 p.m.
New subject: Gentoo jack wiki page wrong? (was Re: 200 lines kernel patch)
On 11/21/2010 6:43 AM, Paul Davis wrote:
On Sun, Nov 21, 2010 at 7:43 AM, Jouni
Rinne<l33tmmx(a)gmail.com> wrote:
Paul, as i have always appreciated your input would you mind explaining
why/where it's wrong? I have my Gentoo system set up based on that page
and i'd like to get it right.
Even better would you consider updating the Gentoo wiki so that it is
correct?
Thanks,
Bearcat
Cgroups (using the 'Ubuntu'-style
workaround mentioned in the original article)
+ realtime scheduling works here, on Gentoo, kernel 2.6.34-r12, but needs a
little extra configuration in /etc/security/limits.d/audio.conf, please see here
http://en.gentoo-wiki.com/wiki/JACK#Kernel_Configuration
the information contained
on this page is at best misleading, and
arguably wrong.
_______________________________________________
9:45 p.m.
New subject: Gentoo jack wiki page wrong? (was Re: 200 lines kernel patch)
On Mon, Nov 22, 2010 at 3:41 PM, Bearcat M. Sandor
<hometheater(a)feline-soul.com> wrote:
On 11/21/2010 6:43 AM, Paul Davis wrote:
i don't have time to register and correct every incorrect piece of
text that has accumulated in distro-specific wikis over the last
several years.
the doc in question is wrong about Group Sched, although its true that
it makes life more complicated and should probably be left off.
it also continues to perpetuate the "nice" error in limits.conf AND
provides a fixed value for memlock.
my best take on all this stuff will always be found at
http://jackaudio.org/faq and will updated from time to time as needed.
On Sun, Nov 21, 2010 at 7:43 AM, Jouni Rinne<l33tmmx(a)gmail.com> wrote:
Paul, as i have always appreciated your input would you mind explaining
why/where it's wrong? I have my Gentoo system set up based on that page and
i'd like to get it right.
Even better would you consider updating the Gentoo wiki so that it is
correct? Cgroups (using the 'Ubuntu'-style
workaround mentioned in the original
article)
+ realtime scheduling works here, on Gentoo, kernel 2.6.34-r12, but needs
a
little extra configuration in /etc/security/limits.d/audio.conf, please
see here
http://en.gentoo-wiki.com/wiki/JACK#Kernel_Configuration
the information contained on this page is at best misleading, and
arguably wrong.
_______________________________________________
4913
days inactive
4917
days old
linux-audio-user@lists.linuxaudio.org
17 comments
11 participants
participants (11)
-
Atte André Jensen -
Bearcat M. Sandor -
Chris Cannam -
Darrin Thompson -
david -
Jouni Rinne -
Niels Mayer -
Paul Davis -
Philipp Überbacher -
Ray Rashif -
torbenh