Philipp Ãberbacher wrote:
Excerpts from david's message of 2010-11-20 19:57:45 +0100:
Ray Rashif wrote:
On 21 November 2010 02:33, torbenh <torbenh@xxxxxx> wrote:
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@xxxxxxxx> 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.
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.
Sounds like slashdot rephrased the lkml discussion :)
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@xxxxxxxxxxxxx
authenticity, honesty, community
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
