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 :) The whole thing needs cgroups enabled, is this a good idea at all? _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
