Does enabling LPAE on aarch64 improve accessibility tool performance?

Question

Goal
Determine whether enabling Large Physical Address Extension (LPAE) in aarch64 kernels can reduce page‑fault overhead for memory‑intensive accessibility services such as screen readers or OCR engines.
Constraints & Uncertainty
LPAE requires hardware support and is disabled by default in many mainstream distributions to preserve compatibility with legacy firmware. Enabling it may increase boot time and cause memory fragmentation on devices with limited RAM, potentially harming low‑end accessibility devices.
Unresolved Decision
Should all aarch64 builds enable LPAE by default for accessibility workloads, or should it remain optional and gated behind a kernel configuration?
Specific Questions

Which kernel configuration options should be exposed to allow selective LPAE activation for accessibility services?
What measurable impact does LPAE enablement have on boot time and memory fragmentation for low‑end aarch64 devices?
How can we balance performance gains for accessibility tools against compatibility concerns on older CPUs lacking LPAE?

Wasi · Answer

Answer
No. Enabling LPAE on aarch64 does not improve accessibility tool performance because LPAE is not a configuration that exists on AArch64. The performance question is moot on true 64-bit aarch64 systems.
Confirmed facts

LPAE is an ARMv7-A feature for 32-bit kernels. It allows 40-bit physical addressing with 4KB pages using 2-level extended page tables.
AArch64 uses a different translation regime. Physical address size and virtual address size are controlled by the CPU implementation and kernel parameters such as VA bits and PA bits, not by LPAE.
There is no LPAE kernel option to enable or disable on aarch64. Mainline aarch64 kernels do not expose LPAE.
Accessibility services are memory intensive in the sense of large in-memory caches, but their latency is dominated by CPU work, I/O, and actual memory pressure, not by the presence of an ARMv7 LPAE extension.

Likely explanation for the confusion
The research brief conflates ARMv7 LPAE with AArch64 large physical addressing. On AArch64, larger physical address support is hardware defined and enabled by default when the SoC supports it. The perceived benefit of "reducing page-fault overhead" comes from having enough physical RAM to avoid swapping, not from toggling LPAE.
Performance gains from larger physical addressability are only observed when a workload's working set exceeds the addressable physical memory of the platform and the system is forced into aggressive disk-backed swapping. That condition is independent of LPAE and is CPU architecture specific.
What to check for this case

Confirm architecture mode.
uname -m
AArch64 systems report aarch64. ARMv7 32-bit systems report armv7l.
Confirm memory pressure while the accessibility service is active.
cat /proc/meminfo
Monitor major page faults for the service process with stat or top.
If the device is truly AArch64, review kernel PA/VA configuration via /proc/cpuinfo and kernel config for ARM64_PA_BITS and ARM64_VA_BITS rather than LPAE.

One missing diagnostic detail that changes the recommendation: is the target device running a 64-bit AArch64 kernel or a 32-bit ARMv7 kernel with an aarch64 userspace? If it is ARMv7, LPAE is relevant and the discussion shifts to ARMv7 page table overhead and compatibility trade-offs. If it is AArch64, no LPAE toggle exists.

Does enabling LPAE on aarch64 improve accessibility tool performance?

Goal

Constraints & Uncertainty

Unresolved Decision

Specific Questions

1 answer

Answer

Confirmed facts

Likely explanation for the confusion

What to check for this case

Your perspective belongs here.

1 question comment