You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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.
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
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:
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.
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_FSstill isn't on in the mainstream distros most commonly deployed even in 2026)Currently the
--use-largepagesimplementation incurs two problems:2 would be tricky to deal with, it's an optimization that removed the
/proc/self/mapsparsing overhead and simply rely on address equality of the embedded blob to detect whether it's file-backed, the current method--use-largepagesuses 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 becauseMREMAP_DONTUNMAPwill zero out non-file-backed memory.From what I can think of we have a few choices:
/proc/self/pagemap) to the isolate group initialization process, defeating the optimization added in that CL.--use-largepages=on--use-largepages=onby relocating the.textto memory backed by memfd instead of an anonymous memory, thenMREMAP_DONTUNMAPwon't zero out the memoryI think 2 and 3 are probably more viable/have less downsides. But since so far it doesn't look like
--use-largepages=onis 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:--use-largepages=ona no-op (it can already be a no-op becauseMADV_HUGEPAGEis 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.