-
Notifications
You must be signed in to change notification settings - Fork 178
Include debug.config in KBUILD_CONFIG_EXTRA
#1400
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
| KBUILD_CONFIG_EXTRA = "${@bb.utils.contains('DISTRO_FEATURES', 'hardened', '${S}/kernel/configs/hardening.config', '', d)}" | ||
| KBUILD_CONFIG_EXTRA:append:aarch64 = " ${S}/arch/arm64/configs/prune.config" | ||
| KBUILD_CONFIG_EXTRA:append:aarch64 = " ${S}/arch/arm64/configs/qcom.config" | ||
| KBUILD_CONFIG_EXTRA:append = " ${S}/kernel/configs/debug.config" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. These options are not suitable for the kernel that is used for anything else than debugging
...
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
CONFIG_DEBUG_OBJECTS_FREE=y
CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y
CONFIG_DEBUG_OBJECTS_RCU_HEAD=y
CONFIG_DEBUG_OBJECTS_TIMERS=y
CONFIG_DEBUG_OBJECTS_WORK=y
CONFIG_DEBUG_PER_CPU_MAPS=y
CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_VIRTUAL=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_VM_PGFLAGS=y
CONFIG_DEBUG_VM_RB=y
CONFIG_DEBUG_VM_VMACACHE=y
CONFIG_KASAN=y
....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
meta-qcom nightly builds are used for long‑duration tests to uncover stability and memory issues. These issues are difficult to reproduce and often require multiple iterations over several hours or even days to replicate and capture logs. Therefore, it is essential to always collect the right logs during the run, which requires enabling the appropriate debug configurations.
Kernel configuration options known to impact general performance have already been removed from debug.config in qualcomm-linux/kernel@a3d2355.
To name few disabled configs from above list.
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y
CONFIG_KASAN=y
If there are additional options that are not needed, they can also be considered for removal. However, retaining the non‑problematic debug options is necessary for these tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. The config still contains a lot of useless debug options which however will impact the behaviour and the performance of the running system (thus triggereing behaviour and bugs different from the ones which are visible on the production system). For example, what kind of issues do you want to uncover with CONFIG_DEBUG_OBJECTS? What is the impact of CONFIG_DEBUG_VM or CONFIG_DEBUG_VIRTUAL? On the other hand, the mentioned commit has disabled (among others) one of the few really necessary and sensible Kconfig debug options.
Overall, default meta-qcom builds should be suitable for the production. If one needs a debug build, they can create it on their own. Feel free to provide support for it via e.g. DISTRO_FEATURES or any other available way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In #1276 (comment), it is suggested that builds be tuned for performance using a DISTRO_FEATURE, which is for production requirements. However, the recommendation here to keep debug options under another DISTRO_FEATURE. This creates a conflict: one feature aims for maximum performance, while the other aims for maximum debuggability.
I believe there should be a single, mutually exclusive feature. Either performance or debuggability but not both at the same time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I wrote, I think the default should be production-ready. Which means, no extra optimisations, but also no extra debugs. I don't see a problem with enabling debugfs, but options from debug.config are definitely an overkill. I would not run such a kernel anywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So there are going to be 3 variants of builds
- Default/production
- Performance optimized
- Extended debug enabled
Added two new distros via qualcomm-linux/meta-qcom-distro#140 to facilitate this discussion.
@ndechesne @idlethread @ricardosalveti are you aligned with this approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless the defconfig is aligned between the current qcom-next build and the requirement mentioned in #1276, it won’t be possible to club items 1 and 2 together.
If we all agree to handle this in qualcomm-linux/kernel instead of meta-qcom, then item 1 can be dropped.
Also, please note that adding quiet to the kernel command line reduces the number of logs but does not completely disable the console. For performance builds, the expectation is to eliminate the console entirely to ensure more accurate benchmarking results. If that is indeed the requirement, then we will need a 3rd build variant with the console fully disabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default image should be production. Always. There should be no need for a separate "performance-optimized" config.
Next, if we need, we can add the "debug" variant. But I would rather not build it through meta-qcom CI. Its usage should be very, very limited. By default all the testing should be preformed using the production builds.
When `extended-debug` DISTRO_FEATURE is enabled, include `debug.config` in KBUILD_CONFIG_EXTRA to enable additional kernel debug options during build. Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>
When `extended-debug` DISTRO_FEATURE is enabled, include `debug.config` in KBUILD_CONFIG_EXTRA to enable additional kernel debug options during build. Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>
Test run workflowTest jobs for commit 184165e
|
Test Results 14 files - 5 14 suites - 54 2h 26m 56s ⏱️ + 1h 28m 45s For more details on these failures, see this check. Results for commit 184165e. ± Comparison against base commit 3cfd302. This pull request removes 24 and adds 2 tests. Note that renamed tests count towards both. |
Include
debug.configin KBUILD_CONFIG_EXTRA to enable additionalkernel debug options during build.