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.
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.sulli...@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.sulli...@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfi...@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 <kamen...@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 <kamen...@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@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"
--
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
