[alsa-devel] Audio Mini Summit 2015, 8th October, Dublin

[Lars-Peter Clausen]

On 10/12/2015 10:46 AM, Takashi Iwai wrote:
> On Fri, 09 Oct 2015 15:29:23 +0200,
> Lars-Peter Clausen wrote:
>>
>> On 10/08/2015 04:29 PM, Lars-Peter Clausen wrote:
>>> On 10/08/2015 04:13 PM, Lars-Peter Clausen wrote:
>>>> On 10/07/2015 05:20 PM, Mark Brown wrote:
>>>>> On Mon, Oct 05, 2015 at 12:17:52AM +0100, Mark Brown wrote:
>>>>>> [This message is BCCed to everyone currently on the signup list]
>>>>>>
>>>>>> As previously announce the audio mini-summit for this year will be this
>>>>>> Thursday (8th August) at CCD in Dublin.  Topics we currently have on the
>>>>>> list for discussion are:
>>>>>
>>>>> Current list:
>>>>>
>>>>>  - Power saving and general system design decisions (is what we're doing
>>>>>    lining up with modern hardware with things like multiple output
>>>>>    streams?).
>>>>>  - Documentation.
>>>>>  - alsa-lib releae plans.
>>>>>  - What to do with HDMI and its integration with graphics.
>>>>>  - Test tools (Intel BAT and others).
>>>>>  - BATCH flag.
>>>>>  - Fuzz control PCM APIs.
>>>>>  - Splitting out root only controls.
>>>>>  - ACPI simple-card and general generic card support.
>>>>>  - Topology & media controller integration.
>>>>>  - Kernel tinification.
>>>>>  - Android <-> alsa-lib configuration translation.
>>>>>  - HDA restructuring.
>>>>>   - Support for DisplayPort MST.
>>>>>  - PCM core simplification - the code is currently quite complex!
>>>>>  - Soundwire driver support plans.
>>>>>  - ASoC multichannel.
>>>>>  - Random DAPM changes.
>>>>
>>>> Media controller:
>>>> http://blogs.s-osg.org/working-complicated-problems-media-controller-workshop/
>>>
>>> And to give some more background information on how the constraints
>>> refinement works: http://metafoo.de/alsa_constraints.html
>>>
>>> It's not yet complete but should still give you and idea
>>
>> Btw. when you try to size optimize the kernel have you tried to build stuff
>> with link-time-optimization? A lot of the constraints refinement code is
>> helper function that are only used by certain drivers. So with LTO also
>> those helper function would be removed.
> 
> Yeah, I suggested a similar thing to Keyon before the meeting.
> But I wonder whether LTO takes effect if the module is enabled.
> AFAIK, Intel want to keep the modules (despite of the demanded code
> reduction), as they seem to try the generic solution.  If the module
> is enabled, essentially all exported symbols have to stay, so LTO
> can't rip off anything.

Well, even if you do a modular build you still need to build both modules
and the kernel from the same Kconfig. You can't decide that you later on
want to enable or disable certain modules and then only re-build those. So
at least in theory all the information about which functions are used in the
modules and which are not is available and could be used by the LTO phase.
But I've never worked with kernel LTO and have no idea whether that works in
practice or not.

But I think this is still the path that I'd recommend people to peruse.
Since this is a generic approach and once you've figure it out you should be
able to see the maximum amount of savings rather than the approch where you
look at each module separately and need to go through them and identify
functionality that can be removed. Or even try to remove vital parts of the
framework completely.

E.g. I'd consider parameter refining a vital part of ALSA and the core
functionality of it is rather compact. But it provides a lot of helper
functions of which only some are going to be used if you built a reduced
kernel. So rather then completely disabling parameter refining use LTO to
remove the unused helper functions.

> 
> A possible workaround that came to my mind is to build both built-in
> and modules.  The former contains only symbols referred inside the
> built-in kernel while the latter module contains the rest exported
> symbols.  But, the initialization is the problem in this case, so it's
> not so straightforward for now...
> 
> 
> Takashi
>