feat(kernel): enable DAMON on x86_64 - #18050
Conversation
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
There was a problem hiding this comment.
Pull request overview
Enables DAMON monitoring and its sysfs interface for the x86_64 Azure Linux kernel.
Changes:
- Enables DAMON virtual and physical address monitoring.
- Keeps optional DAMON policies disabled.
- Synchronizes rendered configuration and refreshes the lock fingerprint.
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
base/comps/kernel/6.18-x86_64-azl.config |
Enables DAMON for x86_64. |
specs/k/kernel/6.18-x86_64-azl.config |
Synchronizes rendered configuration. |
locks/kernel.lock |
Refreshes the component fingerprint. |
0011d8e to
efb816c
Compare
| CONFIG_INFINIBAND_ADDR_TRANS_CONFIGFS=y | ||
| CONFIG_INFINIBAND_VIRT_DMA=y | ||
| # CONFIG_INFINIBAND_BNXT_RE is not set | ||
| CONFIG_INFINIBAND_BNXT_RE=m |
reubeno
left a comment
There was a problem hiding this comment.
I'm not familiar with this particular kernel feature; I'd find it helpful to understand what use case you have in mind, whether there's runtime performance overhead of being enabled (but not activated), etc.
(FWIW -- It looks like this feature wasn't enabled in Azure Linux 3.0, and there's a mix of enablement/disablement across some other distros.)
| # Data Access Monitoring | ||
| # | ||
| # CONFIG_DAMON is not set | ||
| CONFIG_DAMON=y |
There was a problem hiding this comment.
Is there a reason this PR proposes enabling only on x86_64 and not also aarch64?
There was a problem hiding this comment.
I can enable it for arm as well. Was not sure if kernel configs were suppose to be mirrored, figured it was a task, only for x86 from my isde
There was a problem hiding this comment.
Let's mirror to both here and align with Fedora on these configs
| CONFIG_INFINIBAND_ADDR_TRANS_CONFIGFS=y | ||
| CONFIG_INFINIBAND_VIRT_DMA=y | ||
| # CONFIG_INFINIBAND_BNXT_RE is not set | ||
| CONFIG_INFINIBAND_BNXT_RE=m |
There was a problem hiding this comment.
Is this intended as a stacked PR on top of your other one that enables this option?
There was a problem hiding this comment.
Yes, given the config was hashed, i wanted to avoid having to regenerate the hash after the bntx module was merged.
efb816c to
eeffd0f
Compare
| CONFIG_INFINIBAND_ADDR_TRANS_CONFIGFS=y | ||
| CONFIG_INFINIBAND_VIRT_DMA=y | ||
| # CONFIG_INFINIBAND_BNXT_RE is not set | ||
| CONFIG_INFINIBAND_BNXT_RE=m |
Hey @reubeno Wanted to use it to profile applications and see if we can use this telemetry to better right size them(memory footprint). Well thats the idea. All the auto reclaim options were left off, only flipped the observability side. |
Set CONFIG_INFINIBAND_BNXT_RE=m, reenabling RDMA support on Broadcom NetXtreme NICs. Bump azl_pkgrelease to 10 with a %changelog entry and refresh the kernel lock input-fingerprint. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Enable CONFIG_ACPI_APEI_GHES=y (Generic Hardware Error Source) in the x86_64 kernel config to support APEI/GHES firmware-first hardware error reporting. aarch64 already has GHES enabled. All select dependencies (ACPI_HED, IRQ_WORK, GENERIC_ALLOCATOR) and the ACPI_APEI dependency are already satisfied, so this is an additive change. Bumps azl_pkgrelease 10 -> 11 with a matching changelog entry. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Enable CONFIG_USB_NET_RNDIS_HOST=m in the AzL4 x86_64 kernel config. This pulls in the required USB usbnet chain (USB_NET_DRIVERS=m, USB_USBNET=m, USB_NET_CDCETHER=m, which RNDIS_HOST selects). All other USB net drivers are explicitly kept disabled for minimal divergence; USB_RTL8153_ECM is a non-prompt helper forced on by CDCETHER. Bump %azl_pkgrelease 11 -> 12 and add changelog entry. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
eeffd0f to
d9241d5
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 7 out of 8 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (4)
base/comps/kernel/6.18-x86_64-azl.config:6188
- The PR is described as enabling DAMON, but this also enables the Broadcom RoCE driver and changes its required-config policy under a separate work item. Please either remove this stacked feature and its associated generated/policy/release changes, or document the expanded PR scope and validation explicitly.
CONFIG_INFINIBAND_BNXT_RE=m
base/comps/kernel/6.18-x86_64-azl.config:674
- The PR is described as enabling DAMON, but this also enables ACPI APEI GHES and adds a separate policy/work-item change. That materially expands the kernel behavior beyond the stated scope. Please either remove the stacked GHES changes (including its policy/changelog/release/rendered state) or update the PR title and description to explicitly include and justify this feature.
CONFIG_ACPI_APEI_GHES=y
base/comps/kernel/6.18-x86_64-azl.config:1334
- None of the new DAMON settings appears in
azl4-os-required-kernel-configs.json. The CI checker only validates names present in that policy (check_config.py:75-96), so it would not catch a later regression that disables DAMON or its selected interfaces. Add the four enabled values—and the three explicitly disabled opt-ins if those are requirements—to thekernelx86_64 override with a justification.
CONFIG_DAMON=y
CONFIG_DAMON_VADDR=y
CONFIG_DAMON_PADDR=y
CONFIG_DAMON_SYSFS=y
base/comps/kernel/6.18-x86_64-azl.config:1331
- This changes the built kernel configuration, but the PR description records only config regeneration/render synchronization and the lock refresh. Repository policy requires an output-affecting component change to be built and the resulting RPMs inspected and smoke-tested in a mock chroot. Please add the kernel build and applicable mock validation results (or explicitly document why a smoke test cannot be performed and what was verified instead).
CONFIG_DAMON=y
Enable the Data Access Monitoring (DAMON) framework in the x86_64 kernel config: CONFIG_DAMON=y CONFIG_DAMON_VADDR=y # virtual-address-space monitoring CONFIG_DAMON_PADDR=y # physical-address-space monitoring CONFIG_DAMON_SYSFS=y # sysfs control interface DAMON_RECLAIM/LRU_SORT/STAT are left off (opt-in actuators); the sub-options are declared explicitly so olddefconfig/listnewconfig stays consistent now that the parent is enabled. Stacked on the USB RNDIS host enablement (release 12). Bumps azl_pkgrelease 12 -> 13 with a matching changelog entry. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
d9241d5 to
3d5d602
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 7 out of 8 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (2)
base/comps/kernel/6.18-x86_64-azl.config:1334
- The kernel-config CI validates only options listed in the intentional-policy JSON, but this PR adds no
CONFIG_DAMON*expectations there. Consequently CI would not detect a later regression that disables the framework or its requested interfaces. Addkernel/x86_64policy entries for these enabled values and the deliberately disabled opt-in subfeatures.
CONFIG_DAMON=y
CONFIG_DAMON_VADDR=y
CONFIG_DAMON_PADDR=y
CONFIG_DAMON_SYSFS=y
base/comps/kernel/6.18-x86_64-azl.config:674
- The title and description scope this PR to DAMON, but the diff also enables GHES, USB RNDIS (and supporting USB networking options), and
BNXT_RE, with corresponding policy and release-history changes. These alter the shipped kernel beyond the stated scope. Rebase/drop the unrelated commits, or explicitly broaden the PR scope and validation evidence to cover all four feature changes.
CONFIG_ACPI_APEI_GHES=y
Enable the Data Access Monitoring framework in the x86_64 kernel config:
CONFIG_DAMON=y
CONFIG_DAMON_VADDR=y # virtual-address-space monitoring
CONFIG_DAMON_PADDR=y # physical-address-space monitoring
CONFIG_DAMON_SYSFS=y # sysfs control interface
DAMON_RECLAIM/LRU_SORT/STAT are left off (opt-in). The sub-options are
declared explicitly so process_configs.sh (olddefconfig + listnewconfig)
stays consistent now that the parent exposes them. Source and rendered
config kept in sync via the verbatim config overlay; kernel.lock
input-fingerprint refreshed via 'azldev comp update -p kernel'.
Check
#17874
#18224
#18226