[linux-yocto] [yocto-kernel-cache][PATCH] features/systemtap/systemtap.cfg: enable CONFIG_KERNEL_DEBUG

Wed Mar 14 08:54:20 PDT 2018

On Wed, 14 Mar 2018, Bruce Ashfield wrote:

> On 2018-03-14 10:41 AM, Victor Kamensky wrote:
>> Hi Bruce,
>> 
>> On Wed, 14 Mar 2018, Bruce Ashfield wrote:
>> 
>>> As it turns out, Ross is reporting a big performance degradation in the 
>>> kernel
>>> in footprint, packaging and build time.
>>> 
>>> It completely slipped my mind when looking at this commit, that we went 
>>> through
>>> a split two years ago for that very same issue.
>>> 
>>> For now, I'm going to revert this,
>> 
>> Please note that after revert in your regular build kernels will not
>> be debuggable, because it is missing symbols. For example for investigation 
>> like [1] where kernel hangs where one can pick at
>> hangged kernel quickly after 'runnqemu qemuparam="-S -s"'. It is
>> not possible without symbols.
>
> That's fully understood. But we cannot have that config on for
> the standard kernel build. That's what the developer ktype is for.
>
>> 
>>> and then work systemtap properly into the
>>> developer kernel type. The issue is that the standard kernel includes 
>>> systemtap
>>> by default (it probably shouldn't), and hence is picking up the 
>>> DEBUG_KERNEL
>>> option .. and that's causing the issues.
>> 
>> Even if you revert commit please do not remove systemtap fragment
>> from regular kernel. I said that without CONFIG_KERNEL_DEBUG
>> kernel tracing does not make sense. But besides kernel systemtap
>> can do user-land process tracing, this one works OK even if symbols
>> are not in kernel.
>> 
>> Instead of removing systemtap.cfg from regular kernel, it would be
>> better to add separate debuginfo.cfg that would enable debug
>> symbols kernle and have some quick way through which one can add
>> symbols through simple local.conf setting. So if run into situation
>> like [1], and need to look at kernel with gdb or run systemtap
>> against it, one can just add line to local.conf and rebuild kernel.
>
> There's already a fragment for that purpose and it is what the
> developer kernel type uses. Anyone can include that fragment via
> a bbappend.
>
> The developer kernel type includes the standard kernel, so it is
> a superset .. so yes, I can leave systemtap in place and the developer
> kernel type just finishes the enablement of it.

I will look at kernel ktype mechanism. But if in developper
fragment there are some other options, it may not be suitable
for use cases that I have in mind. Suppose one runs into the
problem with kenel and would like to debug it with gdb or write
systemtap script to investigate it. There should be a
way just to add symbols to it and leave all other configs intact,
because who knows maybe those config will change kernel behavior
and issue won't be reprodicible anymore. So I think there should
be a way to enable DEBUG_INFO symbols only quickly for any given
config. I'll try to look at how to do it, and will post some
RFC patches for it.

Thanks,
Victor

> Bruce
>
>> 
>> [1] 
>> http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148587.html 
>> 
>> Thanks,
>> Victor
>> 
>>> For now, you can build the developer kernel type, or add the developer 
>>> kernel
>>> configuration fragment via a bbappend, and you'll have a functional 
>>> systemtap.
>>> 
>>> I can move systemtap out of the standard kernel and only into the 
>>> developer
>>> kernel, since as you say, it isn't functional without this option.
>>> But, that ktype
>>> hasn't gotten a lot of mileage (despite being around for two years),
>>> so I'll need
>>> to run some tests before I can truly move the fragment over and confirm 
>>> that
>>> it works.
>>> 
>>> So again, for now, I'll revert this, but will work on getting the
>>> ktypes fixed up
>>> as well.
>>> 
>>> Cheers,
>>> 
>>> Bruce
>>> 
>>> 
>>> commit a7b57bb54cace686911faae9a8eace3b9cbf8145
>>> Author: California Sullivan <california.l.sullivan at intel.com>
>>> Date:   Wed Feb 17 16:47:10 2016 -0800
>>> 
>>>    ktypes: add developer ktype
>>> 
>>>    The developer ktype enables EMBEDDED, EXPERT, and DEBUG_KERNEL,
>>>    opening up more kernel options and setting some defaults.
>>> 
>>>    Signed-off-by: California Sullivan <california.l.sullivan at intel.com>
>>>    Signed-off-by: Bruce Ashfield <bruce.ashfield at windriver.com>
>>> 
>>> :000000 100644 000000000000... ee04ec720188... A
>>> ktypes/developer/developer.cfg
>>> :000000 100644 000000000000... cf2c0e6519d5... A
>>> ktypes/developer/developer.scc
>>> 
>>> 
>>> 
>>> On Sat, Mar 3, 2018 at 9:03 PM, Victor Kamensky <kamensky at cisco.com> 
>>> wrote:
>>>> Need to enable CONFIG_KERNEL_DEBUG in systemtap feature, otherwise
>>>> CONFIG_DEBUG_INFO set by systemtap.cfg does not have any effect since
>>>> it depends on CONFIG_KERNEL_DEBUG and is set off in resulting config.
>>>> So systemtap cannot find DWARF information in resulting kernel.
>>>> 
>>>> Signed-off-by: Victor Kamensky <kamensky at cisco.com>
>>>> ---
>>>>  features/systemtap/systemtap.cfg | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>> 
>>>> diff --git a/features/systemtap/systemtap.cfg 
>>>> b/features/systemtap/systemtap.cfg
>>>> index acc2405..858447c 100644
>>>> --- a/features/systemtap/systemtap.cfg
>>>> +++ b/features/systemtap/systemtap.cfg
>>>> @@ -1,4 +1,5 @@
>>>>  CONFIG_RELAY=y
>>>> +CONFIG_DEBUG_KERNEL=y
>>>>  CONFIG_DEBUG_INFO=y
>>>>  CONFIG_DEBUG_FS=y
>>>>  CONFIG_MODULES=y
>>>> -- 
>>>> 2.7.4
>>>> 
>>>> -- 
>>>> _______________________________________________
>>>> linux-yocto mailing list
>>>> linux-yocto at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/linux-yocto
>>> 
>>> 
>>> 
>>> -- 
>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>> thee at its end"
>>> 
>
>