Skip to content
This repository was archived by the owner on Sep 8, 2025. It is now read-only.
This repository was archived by the owner on Sep 8, 2025. It is now read-only.

2 MiB aligned code section isn't fully mapped to 2 MiB pages (large_page-c) #84

@gsauthof

Description

@gsauthof

Starting point: Running an executable that was linked with -Wl,-zcommon-page-size=2097152 -Wl,-zmax-page-size=2097152 under IODLR_USE_EXPLICIT_HP=1 LD_PRELOAD=/path/to/liblppreload.so.

Expectation: The code mapping is completely mapped to 2 MiB hugepages.

Actual result:

  1. The first 2 MiB are still on 4 KiB pages.
  2. There is a tail of 1.5 MiB or so that is still on 4 KiB pages.

Discussion:

  1. This is due to the liblppreload library parsing the ELF headers and sh_addr begins 20 KiB after the actual 2 MiB aligned r-xp memory mapping start address and thus the library aligns sh_addr up to the next 2 MiB boundary.
  2. This is caused by the linker aligning the start addresses to 2 MiB but not the segment size. However, in my tests, the address space after the code segment end and the next segment start wasn't mapped such that the end-address could actually be aligned up instead of down.

An alternative and arguably simpler approach to traversing ELF headers is to parse /proc/$pid/smaps and remap complete r-xp mappings to huge pages. That way one can also detect whether it's is safe to align the end of a mapping up to the next 2 MiB boundary.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    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