[LAU] 200 lines kernel patch

david gnome at hawaii.rr.com
Mon Nov 22 03:53:56 UTC 2010


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 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 :)

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 at hawaii.rr.com
authenticity, honesty, community


More information about the Linux-audio-user mailing list