[OE-core] 2.7% build time regression caused by enabling debug/printk.scc KERNEL_FEATURE]

[Sullivan, California L]

Adding the debug-kernel fragment to the printk fragment was probably a
mistake on my part. I don't see anything that requires it.

I'm also seeing another issue: TTY_PRINTK depends on EXPERT, which is
only enabled on the developer kernel by default, so you currently won't
be getting that option. From there, if we were to enable EXPERT,
DEBUG_KERNEL then gets selected automatically and we essentially end up
where we started and have the build time regression.

Stuff to think about on my end I suppose. In the mean time I +1 removing
the debug-kernel include from printk.scc.

---
Cal

On 07/27/2016 07:31 AM, Bruce Ashfield wrote:
> On 2016-07-27 09:18 AM, Ed Bartosh wrote:
>> On Wed, Jul 27, 2016 at 09:06:44AM -0400, Bruce Ashfield wrote:
>>> On 2016-07-27 08:28 AM, Ed Bartosh wrote:
>>>> Hi Bruce,
>>>>
>>>> Thank you for your suggestion to experiment with configuration options!
>>>>
>>>>> On 2016-07-26 10:32 AM, Ed Bartosh wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> We've noticed quite big increase of core-image-minimal build time caused by commit
>>>>>> d55b7650d305ffad953dd36595ee6b9aa8df5a72 linux-yocto: Enablei debug/printk.scc KERNEL_FEATURE on qemuall machines.
>>>>>>
>>>>> That commit only enables the following options:
>>>>>
>>>>> CONFIG_PRINTK=y
>>>>> CONFIG_PRINTK_TIME=y
>>>>>
>>>>> CONFIG_EARLY_PRINTK=y
>>>>>
>>>>> CONFIG_EARLY_PRINTK_DBGP=y
>>>>> CONFIG_EARLY_PRINTK_EFI=y
>>>>> CONFIG_TTY_PRINTK=y
>>>>>
>>>>> And yes, that will add some size to the kernel, but I'm not seeing
>>>>> similar size increases here.
>>>>>
>>>>> If you take a look through the kernel source and build, there are
>>>>> relatively few additions to the actual kernel build that change
>>>>> based on those options, and most of them are runtime changes versus
>>>>> build-time changes.
>>>>>
>>>> The actuall difference in configuration is bigger as far as I can see:
>>>> $ diff -u ../build-kernel/tmp/work/qemux86_64-poky-linux/linux-yocto/4.4.14+gitAUTOINC+4800a400d5_8361321fec-r0/image/boot/config-4.4.14-yocto-standard
>>>> tmp/work/qemux86_64-poky-linux/linux-yocto/4.4.14+gitAUTOINC+4800a400d5_8361321fec-r0/image/boot/config-4.4.14-yocto-standard | grep '^+C'
>>>> +CONFIG_CONSOLE_POLL=y
>>>> +CONFIG_PRINTK_TIME=y
>>>> +CONFIG_DEBUG_INFO=y
>>>> +CONFIG_DEBUG_KERNEL=y
>>>> +CONFIG_SCHED_DEBUG=y
>>>> +CONFIG_DEBUG_PREEMPT=y
>>>> +CONFIG_KGDB=y
>>>> +CONFIG_KGDB_SERIAL_CONSOLE=y
>>>> +CONFIG_KGDB_LOW_LEVEL_TRAP=y
>>>> +CONFIG_KGDB_KDB=y
>>>> +CONFIG_KDB_DEFAULT_ENABLE=0x1
>>>> +CONFIG_KDB_KEYBOARD=y
>>>> +CONFIG_KDB_CONTINUE_CATASTROPHIC=0
>>>> +CONFIG_EARLY_PRINTK_DBGP=y
>>>> +CONFIG_EARLY_PRINTK_EFI=y
>>>> +CONFIG_DEBUG_RODATA=y
>>>> +CONFIG_DEBUG_RODATA_TEST=y
>>>> +CONFIG_X86_DEBUG_FPU=y
>>>>
>>>> I guess the reason of this is that printk.scc includes debug-kernel.scc,
>>>> which brings more config options:
>>>> CONFIG_DEBUG_KERNEL=y
>>>> CONFIG_DEBUG_INFO=y
>>>> CONFIG_DEBUG_PREEMPT=y
>>>>
>>>> That probably explains the difference in kernel size and compile time.
>>>>
>>> Yup.
>>>
>>>> After removing 'include debug-kernel.scc' the difference in
>>>> configuration became more reasonable:
>>>> +CONFIG_PRINTK_TIME=y
>>>> +CONFIG_EARLY_PRINTK_DBGP=y
>>>> +CONFIG_EARLY_PRINTK_EFI=y
>>>>
>>>> And the size of kernel and modules became almost the same as before
>>>> enabling printk feature.
>>>>
>>>> Considering that the rest of the options from printk.scc don't appear in
>>>> the result configuration even if debug-kernel.scc is included I hope
>>>> it should be ok to remove 'include debug-kernel.scc' from printk.scc.
>>>>
>>>> Does it make sense for you?
>>> It does to me. Since we actually have a "developer" kernel type that
>>> is intended for this purpose. Anything that we add to the standard
>>> kernel type should be more surgical.
>>>
>> Looking at guilty commit
>> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/commit/?h=yocto-4.4&id=fd8d90ca69f53d425fdb34fc9a9debac1d0c5f52
>> I'd say that the rest of scc files should be also tested the same way.
>> We may not need to enable all 3 CONFIG_DEBUG options for each of them.
> Adding Cal, since he did the work on this split up.
>
> The profiling feature makes sense with debug kernel being included, but
> I can see some latency top use cases that would be valid with a non
> developer mode kernel (i.e. the standard kernel).
>
> But yes, we don't want fragments that could be included by the standard
> kernel to add typical functionality to add more than they need to
> function. Further tweaking can be done, its part of the iterative
> process on these fragments as we work through use cases.
>
> Bruce
>
>>
>> --
>> Regards,
>> Ed
>>
>