On Tue, May 12, 2026 at 4:31 AM Lance Yang <[email protected]> wrote: > Would it makes sense to apply a similar treatment to huge_zero_folio > as well? > > with CONFIG_PERSISTENT_HUGE_ZERO_FOLIO=y, it is allocated at boot and > never freed, so it should never be written after initialization either :)
Oh, neat, I didn't realize that that feature exists. I guess there are two aspects of making the huge zero folio RO that could be problematic: 1. If the huge zero folio comes from the page allocator, making it read-only might require splitting a huge PUD, which could have performance implications. 2. I vaguely remember arm64 has rules about how PUD/PMD entries in the linear mapping can't be split at runtime at all depending on hardware capabilities, meaning the entire linear mapping may need to be mapped without any huge PUD/PMD entries - IDK if thp_shrinker_init() runs early enough to be excepted from that. See can_set_direct_map() and force_pte_mapping() in arch/arm64/. So making the huge zero folio RO in the linear map would probably require adding a new config flag, connecting that to ARCH_HAS_SET_DIRECT_MAP, and changing one or two places in arm64 memory management.
