[LAU] 200 lines kernel patch

Philipp Überbacher hollunder at lavabit.com
Sun Nov 21 10:15:07 UTC 2010


Excerpts from david's message of 2010-11-20 19:57:45 +0100:
> Ray Rashif wrote:
> > On 21 November 2010 02:33, torbenh <torbenh at gmx.de> 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 at 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.
> 
> 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?



More information about the Linux-audio-user mailing list