ailomaa at warpmail.net
Tue May 8 17:29:42 UTC 2012
On 05/08/2012 05:37 PM, Scott Lavender wrote:
> Hello everyone,
> There are a few interesting developments that should be shared.
> Firstly, there are discussions about moving the -lowlatency kernel
> maintenance into the kernel team as it was pointed out that the patch is
> "something like a two line" patch. I don't actually know how long our
> patch is. And it seems disproportionate to have to rebuild a new kernel
> each time of a security update for such a patch. It was suggested that
> this might become a build option for an existing kernel package maintained
> by UKT.
> Initial discussion with UKT have been fairly positive. They were reducing
> the number of kernel they maintained and it seems that this was contrary to
> their efforts, but it was also realized that the actual maintenance of this
> kernel would be minimal. Queries also were presented about UKT's official
> maintenance and responsibility of the -lowlatency kernel. I'm not sure
> this was answered directly but it appears that because the kernel would be
> built by UKT, it doesn't mean that Canonical or UKT would actually be
> required to support this kernel in an official capacity.
> The next query was where the -lowlatency kernel would therefore be placed
> within the repository. Currently it is in the Universe repository, but the
> existing kernel packages maintained by UKT are in Main. Clean consensus
> was not reached because of ongoing discussion of archive reorganization. I
> will be in a meeting this afternoon which will discuss the archive reorg so
> I should have more information later.
> It should be clear that a final decision has not been reach, but from my
> perspective there doesn't appear to be any clear blockers at this point.
> Therefore I remain hopeful that this will happen as it will greatly reduce
> the workload for the small number of active members.
> Secondly, I hope to talk to some of the JuJu  people about the
> possibility that JuJu might help with Studio in any way. My poor
> explanation is that JuJu is a simplified way to deploy and manage web
> applications in a scalable manner. My hope is that we might find a way to
> help with automating application startup, settings, and connections (if
> applicable) for various work flows, not just audio.
> Lastly, I hope to also talk with Gema , who is leading QA and automated
> testing I believe, about deploying automated testing for Studio. My hope
> is to again, reduce the number of manual tasks we perform in order to
> support Studio.
>  https://juju.ubuntu.com/
>  https://launchpad.net/~gema.gomez
Great news about the kernel.
In fact, another addition to linux confifuration options have made it
possible to add threadirqs as a default boot option to the kernel
without the need to edit the actual code (currently threadirqs option by
default is made possible by a patch to the code):
I am not aware of any other changes to the source, so in that case, all
-lowlatency needs is a different config file for the build.
The specific config options to be used for -lowlatency could perhaps be
discussed. The current ones in Alessio Boganis -lowlatency I believe are:
# CONFIG_RCU_BOOST is not set
# CONFIG_NTP_PPS is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_RCU_CPU_STALL_VERBOSE is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_EXPERT is not set
# CONFIG_NO_HZ is not set
# CONFIG_DEBUG_KERNEL is not set
One option missing here, which is necessary when using the "threadirqs"
as a kernel boot option, but is already apart of the default Ubuntu
I guess it would make sense to add that to the -lowlatency config just
That's my picture of the situation anyway.
More information about the Ubuntu-Studio-devel