Use the Memory Access Optimization with Kdump Enabled feature on an Arm64 architecture-Alibaba Cloud Linux(Alinux)-阿里云帮助中心

Kdump captures a memory image when the Linux kernel crashes, giving you the system memory snapshot needed to analyze the crash. To function, kdump reserves a block of memory at boot time using the crashkernel kernel parameter. On Alibaba Cloud Linux 3 64-bit for Arm, the way that memory is reserved affects linear mapping performance. This topic describes the Memory Access Optimization with Kdump Enabled feature, which addresses that performance impact, and shows how to disable or re-enable it.

Prerequisites

Before you begin, make sure that:

The Elastic Compute Service (ECS) instance runs Alibaba Cloud Linux 3 64-bit for Arm
The kernel version is 5.10.134-17.2 or later

How it works

When crashkernel memory is allocated from direct memory access (DMA) or DMA32 areas, the kernel uses small-page mappings in the linear mapping area so that the reservation size can be adjusted dynamically via /sys/kernel/kexec_crash_size. Small-page mappings degrade memory access performance for addresses in the linear mapping area.

The Memory Access Optimization with Kdump Enabled feature avoids this by reserving crashkernel memory early in the boot process and creating large-page mappings wherever possible. This improves the efficiency of memory accesses through the linear mapping area. The feature is enabled by default—no configuration is required.

Disable the Memory Access Optimization with Kdump Enabled feature

Disabling this feature does not affect kdump itself; kdump continues to function normally.

Warning

Restarting an instance causes a brief outage and may interrupt running services, which can result in data loss. Back up critical data before restarting, and schedule the restart during off-peak hours.

Add defer_reserve_crashmem as a kernel parameter to disable the feature.

sudo grubby --update-kernel="/boot/vmlinuz-$(uname -r)" --args="defer_reserve_crashmem"

Note

To re-enable the feature later, remove the parameter and restart:

sudo grubby --update-kernel="/boot/vmlinuz-$(uname -r)" --remove-args="defer_reserve_crashmem"
sudo reboot

Restart the instance for the change to take effect.
```
sudo reboot
```
After the instance restarts, verify that defer_reserve_crashmem is active in the kernel command line.
```
grep defer_reserve_crashmem /proc/cmdline
```
The output should include defer_reserve_crashmem. For example:
```
BOOT_IMAGE=(hd0,gpt2)/boot/vmlinuz-<kernel-version> ... defer_reserve_crashmem
```
The following figure shows the expected output.

FAQ

Why does crashkernel reserve memory above 4 GB on Arm64?

By default, the crashkernel parameter does not specify a start address, so the kernel places the reservation wherever it fits—often above 4 GB on Arm64 systems. To pin the reservation to a low-memory address, add an @offset suffix to the parameter value.

Use one of the following methods to reserve memory at a specific low-memory address.

Method 1: Reserve a fixed amount at a specific offset

This method reserves a fixed amount of memory starting at a specified address.

Set crashkernel with an explicit size and offset. The example below reserves 320 MB starting at 1024 MB (0x40000000). Adjust the values for your environment.
```
sudo grubby --update-kernel="/boot/vmlinuz-$(uname -r)" --args="crashkernel=320M@1024M"
```
Restart the instance.
Warning
Restarting causes a brief outage and may interrupt running services, potentially resulting in data loss. Back up critical data and schedule the restart during off-peak hours.
```
sudo reboot
```
Verify the parameter is in effect.
```
grep "crashkernel=320M@1024M" /proc/cmdline
```
The output should include crashkernel=320M@1024M. For example:
```
BOOT_IMAGE=(hd0,gpt2)/boot/vmlinuz-<kernel-version> ... crashkernel=320M@1024M
```
The following figure shows the expected output.

Method 2: Reserve memory based on total system memory, at a specific offset

This method scales the reservation size based on how much total memory the instance has, while still anchoring the start address at a fixed low-memory offset.

Set crashkernel with a range-based size and an explicit offset. The example below reserves 0 MB for systems with less than 2 GB, 256 MB for systems with 2–64 GB, and 384 MB for systems with more than 64 GB, all starting at 1024 MB. Adjust the values for your environment.
```
sudo grubby --update-kernel="/boot/vmlinuz-$(uname -r)" --args="crashkernel=0M-2G:0M,2G-64G:256M,64G-:384M@1024M"
```
Restart the instance.
Warning
Restarting causes a brief outage and may interrupt running services, potentially resulting in data loss. Back up critical data and schedule the restart during off-peak hours.
```
sudo reboot
```

Verify the parameter is in effect.

grep "crashkernel=0M-2G:0M,2G-64G:256M,64G-:384M@1024M" /proc/cmdline

The output should include the full parameter string. For example:

BOOT_IMAGE=(hd0,gpt2)/boot/vmlinuz-<kernel-version> ... crashkernel=0M-2G:0M,2G-64G:256M,64G-:384M@1024M

The following figure shows the expected output.

What's next

For the full syntax reference and additional configuration options for the crashkernel parameter, see Configure the crashkernel parameter.