UDS Developments

[Kaj Ailomaa]

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 [0] 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 [1], 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.
>
>
> Cheers,
> ScottL
>
> [0] https://juju.ubuntu.com/
> [1] 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):

CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="threadirqs"

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_PREEMPT=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SLAB=y
# 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 
config is:

CONFIG_IRQ_FORCED_THREADING=y

I guess it would make sense to add that to the -lowlatency config just 
in case.
That's my picture of the situation anyway.