Patchwork Low latency kernel for Quantal

login
register
mail settings
Submitter Tim Gardner
Date May 29, 2012, 7:42 p.m.
Message ID <4FC526BB.6080100@canonical.com>
Download mbox
Permalink /patch/161792/
State New
Headers show

Pull-request

git://kernel.ubuntu.com/rtg/ubuntu-quantal.git lowlatency

Comments

Tim Gardner - May 29, 2012, 7:42 p.m.
On 05/29/2012 10:13 AM, Tim Gardner wrote:
> At UDS I committed to adding a low latency flavour to Quantal if we
> could collapse generic and virtual. It appears that we've been able to
> do so.
>
> After looking at the lowlatency kernel in Precise
> (git://kernel.ubuntu.com/themuso/ubuntu-precise-lowlatency.git) it looks
> like the required config changes are:
>
> CONFIG_HZ=1000
> CONFIG_NO_HZ=n
> CONFIG_PREEMPT=y
> CONFIG_PREEMPT_RCU=y
>
> and some other config options that get enabled as a result of the above
> changes.
>
> The only relevant code patch is 'UBUNTU: SAUCE: Made kernel irq-threaded
> by default' which changes the default behavior of forced IRQ threads to
> enabled, and adds a kernel boot parameter to override the default. I
> propose that we _not_ carry this patch in Quantal if the lowlatency
> installer can add 'threadirqs' to the grub kernel command line.
>
> Thoughts?
>
> rtg

And here is a pull request guaranteed to make your builds take longer.

The only clash that I see in the Quantal archive is with the lowlatency 
meta package. I'll have to add some 'Conflicts:' or 'Replaces:' in the 
mainline kernel meta package. Maybe I can get it removed completely 
since it was auto-synced.

rtg
Leann Ogasawara - May 29, 2012, 9:14 p.m.
On 05/29/2012 12:42 PM, Tim Gardner wrote:
> On 05/29/2012 10:13 AM, Tim Gardner wrote:
>> At UDS I committed to adding a low latency flavour to Quantal if we
>> could collapse generic and virtual. It appears that we've been able to
>> do so.

Having just done some spring cleaning on our list of supported kernel 
flavors, I'm a bit hesitant to just turn around now and throw some more 
back on the list.  Scott, can you refresh my memory what the convincing 
argument was for why we want to add the low latency kernel flavor back 
to list of flavors being maintained?

>> After looking at the lowlatency kernel in Precise
>> (git://kernel.ubuntu.com/themuso/ubuntu-precise-lowlatency.git) it looks
>> like the required config changes are:
>>
>> CONFIG_HZ=1000
>> CONFIG_NO_HZ=n
>> CONFIG_PREEMPT=y
>> CONFIG_PREEMPT_RCU=y
>>
>> and some other config options that get enabled as a result of the above
>> changes.
>>
>> The only relevant code patch is 'UBUNTU: SAUCE: Made kernel irq-threaded
>> by default' which changes the default behavior of forced IRQ threads to
>> enabled, and adds a kernel boot parameter to override the default. I
>> propose that we _not_ carry this patch in Quantal if the lowlatency
>> installer can add 'threadirqs' to the grub kernel command line.

Regardless of where this is maintained, this sounds reasonable 
especially if it eliminates the need of carrying SAUCE patches.

> And here is a pull request guaranteed to make your builds take longer.
>

The pull request looks to do what it claims.  Although as I mentioned 
above I'd like to hear the arguments for why we want this back on our 
list of supported kernel flavors before I'll give my official Ack.

Thanks,
Leann
Scott Lavender - May 29, 2012, 9:44 p.m.
On Tue, May 29, 2012 at 4:14 PM, Leann Ogasawara <
leann.ogasawara@canonical.com> wrote:
>
>
> Having just done some spring cleaning on our list of supported kernel
> flavors, I'm a bit hesitant to just turn around now and throw some more
> back on the list.  Scott, can you refresh my memory what the convincing
> argument was for why we want to add the low latency kernel flavor back to
> list of flavors being maintained?
>
>
> Thanks,
> Leann
>

Hi Leann,

Currently the studio team has to manually update the -lowlatency kernel for
each update. It was suggested that this could be rolled into a build config
making the process much more streamlined and automated.

I believe there was also some discussion regarding maintenance/support. I
seem to recall the outcome was that the kernel team would *not* be
responsible to support this kernel; although I admit I do not remember who
determined this or if it was a consensus.

Please let me know if I can assist in any other way.

Thank you,
ScottL