Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: <ed.bartosh@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: 2.7% build time regression caused by enabling debug/printk.scc KERNEL_FEATURE]
Date: Wed, 27 Jul 2016 10:31:01 -0400	[thread overview]
Message-ID: <5798C5A5.5050909@windriver.com> (raw)
In-Reply-To: <20160727131844.GA31757@linux.intel.com>

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
>



  reply	other threads:[~2016-07-27 14:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1469620052.23580.115.camel@linuxfoundation.org>
2016-07-27 12:28 ` 2.7% build time regression caused by enabling debug/printk.scc KERNEL_FEATURE] Ed Bartosh
2016-07-27 13:06   ` Bruce Ashfield
2016-07-27 13:18     ` Ed Bartosh
2016-07-27 14:31       ` Bruce Ashfield [this message]
2016-07-27 20:06         ` Sullivan, California L
2016-07-27 20:58           ` Aníbal Limón
2016-07-28 19:26             ` Ed Bartosh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5798C5A5.5050909@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=ed.bartosh@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox