Skip to content

Future of --use-largepages=on #64408

Description

@joyeecheung

This was added back in 2018, some background can be found in this issue #16198 - from what I can tell we opted into a user-land relocation to work around the fact that for most kernels in the wild, file-backed .text THP won't work out of the box (i.e. CONFIG_READ_ONLY_THP_FOR_FS still isn't on in the mainstream distros most commonly deployed even in 2026)

Currently the --use-largepages implementation incurs two problems:

  1. It breaks the Node.js binary on WSL1 linux x64 release binary fails to exec on WSL1 #63735
  2. It will stop working in Node.js after we roll in https://chromium-review.googlesource.com/c/v8/v8/+/7985687

2 would be tricky to deal with, it's an optimization that removed the /proc/self/maps parsing overhead and simply rely on address equality of the embedded blob to detect whether it's file-backed, the current method --use-largepages uses to relocate the text region doesn't change the address equality even though the blob is no longer file-backed after relocation, hence it will crash because MREMAP_DONTUNMAP will zero out non-file-backed memory.

From what I can think of we have a few choices:

  1. Convince the upstream to handle the case when the embedded blob is address-equal to the default blob, but is not actually file-backed. From what I can think of this can only be implemented by re-introducing some file parsing overhead (e.g. at least /proc/self/pagemap) to the isolate group initialization process, defeating the optimization added in that CL.
  2. Add a flag to V8 to enforce checking the blob is file-backed via more robust measures other than address equality, then on the Node.js side, enable that flag when --use-largepages=on
  3. Reimplement --use-largepages=on by relocating the .text to memory backed by memfd instead of an anonymous memory, then MREMAP_DONTUNMAP won't zero out the memory

I think 2 and 3 are probably more viable/have less downsides. But since so far it doesn't look like --use-largepages=on is used a lot in the wild, and the alignment in the build it needs breaks WSL1, it also raises another question: do we even want to keep maintaining it? So there's also option 4:

  1. Make --use-largepages=on a no-op (it can already be a no-op because MADV_HUGEPAGE is only advisory, so the feature only ever works on a best-effort basis), and deprecate it eventually.

Opening an issue to see if there's any usage of this feature or if there are other ideas to deal with this. If there are real-world users of this feature it may still be worth it to do 2 or 3, but if there are none, we are probably better off deprecating it to cut the maintenance burden.

Metadata

Metadata

Assignees

No one assigned

    Labels

    memoryIssues and PRs related to the memory management or memory footprint.metaIssues and PRs related to the general management of the project.

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions