Re: [LAU] 200 lines kernel patch

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@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@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@hawaii.rr.com
authenticity, honesty, community
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user