Skip to content

Conversation

@vkraleti
Copy link
Contributor

Include debug.config in KBUILD_CONFIG_EXTRA to enable additional
kernel debug options during build.

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"
Copy link
Contributor

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
....

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

@vkraleti vkraleti Jan 19, 2026

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

  1. Default/production
  2. Performance optimized
  3. 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?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maintaining 3 variants which I think, is an overkill. Why not club #1 (default / production) & #2 (performance optimized) ?

Copy link
Contributor Author

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.

Copy link
Contributor

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>
@github-actions
Copy link

Test run workflow

Test jobs for commit 184165e

@test-reporting-app
Copy link

Test Results

 14 files   -   5   14 suites   - 54   2h 26m 56s ⏱️ + 1h 28m 45s
 13 tests  -  22    9 ✅  -  26  0 💤 ±0   4 ❌ + 4 
124 runs   - 532  113 ✅  - 539  0 💤  - 4  11 ❌ +11 

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.
0_hotplug ‑ hotplug
1_CPUFreq_Validation ‑ CPUFreq_Validation
2_Interrupts ‑ Interrupts
3_cdsp_remoteproc ‑ cdsp_remoteproc
4_adsp_remoteproc ‑ adsp_remoteproc
5_WiFi_Firmware_Driver ‑ WiFi_Firmware_Driver
6_WiFi_OnOff ‑ WiFi_OnOff
7_OpenCV ‑ OpenCV
8_irq ‑ irq
9_BT_ON_OFF ‑ BT_ON_OFF
…
lava ‑ auto-login-action
lava ‑ minimal-boot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants