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.
--
Ubuntu-Studio-devel mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
