From: Usama Arif <usama.arif@linux.dev>
To: WANG Rui <r@hev.cc>
Cc: Liam.Howlett@oracle.com, ajd@linux.ibm.com,
akpm@linux-foundation.org, anshuman.khandual@arm.com,
apopple@nvidia.com, baohua@kernel.org,
baolin.wang@linux.alibaba.com, brauner@kernel.org,
catalin.marinas@arm.com, david@kernel.org, dev.jain@arm.com,
hannes@cmpxchg.org, jack@suse.cz, kas@kernel.org,
kees@kernel.org, kernel-team@meta.com, kevin.brodsky@arm.com,
lance.yang@linux.dev, linux-arm-kernel@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, lorenzo.stoakes@oracle.com,
npache@redhat.com, rmclure@linux.ibm.com, ryan.roberts@arm.com,
shakeel.butt@linux.dev, viro@zeniv.linux.org.uk, will@kernel.org,
willy@infradead.org, ziy@nvidia.com
Subject: Re: [PATCH 3/4] elf: align ET_DYN base to exec folio order for contpte mapping
Date: Fri, 13 Mar 2026 22:47:36 +0300 [thread overview]
Message-ID: <d3f60289-3ea1-43ce-9271-58c8b79bf7a0@linux.dev> (raw)
In-Reply-To: <20260313144213.95686-1-r@hev.cc>
On 13/03/2026 17:42, WANG Rui wrote:
> Hi Usama,
>
Hello!
> Glad to see you're pushing on this, I'm also following it. I first noticed this when rustc's perf regressed after a binutils upgrade. I'm trying to make ld.so to aware THP and adjust PT_LOAD alignment to increase the chances of shared libraries being mapped by THP [1]. As you're probably seen, I'm doing something similar in the kernel to improve it for executables [2].
For us it came about because we use 64K page size on ARM, and none of the
text sections were getting hugified (because PMD size is 512M). I went with
exec_folio_order() = cont-pte size (2M) for 16K and 64K as we can get both page
fault benefit (which might not be that important) and iTLB coverage (due to
cont-pte).
x86 already faults in at 2M (HPAGE_PMD_ORDER) due to force_thp_readahead path in
do_sync_mmap_readahead() so the memory pressure introduced in ARM won't be worse
than what already exists in x86.
>
>> + if (exec_folio_order())
>> + alignment = max(alignment,
>> + (unsigned long)PAGE_SIZE << exec_folio_order());
>
> I’m curious, does it make sense to add some constraints here, like only increasing p_align when the segment length, virtual address, and file offset are all huge-aligned, as I did in my patch? This has come up several times in the glibc review, where increasing alignment was noted to reduce ASLR entropy.
>
Yes I think this makes sense!
Although maybe we should check all segments with PT_LOAD. So maybe something
like below over this series?
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 2d2b3e9fd474f..a0e83b541a7d8 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1116,10 +1116,30 @@ static int load_elf_binary(struct linux_binprm *bprm)
* the hardware cannot coalesce PTEs (e.g. arm64
* contpte) even though the physical memory and
* file offset are correctly aligned.
+ *
+ * Only increase alignment when at least one
+ * PT_LOAD segment is large enough to contain a
+ * full folio and has its file offset and virtual
+ * address folio-aligned. This avoids reducing
+ * ASLR entropy for small binaries that cannot
+ * benefit from contpte mapping.
*/
- if (exec_folio_order())
- alignment = max(alignment,
- (unsigned long)PAGE_SIZE << exec_folio_order());
+ if (exec_folio_order()) {
+ unsigned long folio_sz = PAGE_SIZE << exec_folio_order();
+
+ for (i = 0; i < elf_ex->e_phnum; i++) {
+ if (elf_phdata[i].p_type != PT_LOAD)
+ continue;
+ if (elf_phdata[i].p_filesz < folio_sz)
+ continue;
+ if (!IS_ALIGNED(elf_phdata[i].p_vaddr, folio_sz))
+ continue;
+ if (!IS_ALIGNED(elf_phdata[i].p_offset, folio_sz))
+ continue;
+ alignment = max(alignment, folio_sz);
+ break;
+ }
+ }
/**
* DOC: PIE handling
> [1] https://sourceware.org/pipermail/libc-alpha/2026-March/175776.html
> [2] https://lore.kernel.org/linux-fsdevel/20260313005211.882831-1-r@hev.cc
>
> Thanks,
> Rui
next prev parent reply other threads:[~2026-03-13 19:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 14:51 [PATCH 0/4] arm64/mm: contpte-sized exec folios for 16K and 64K pages Usama Arif
2026-03-10 14:51 ` [PATCH 1/4] arm64: request contpte-sized folios for exec memory Usama Arif
2026-03-19 7:35 ` David Hildenbrand (Arm)
2026-03-10 14:51 ` [PATCH 2/4] mm: bypass mmap_miss heuristic for VM_EXEC readahead Usama Arif
2026-03-18 16:43 ` Jan Kara
2026-03-19 7:37 ` David Hildenbrand (Arm)
2026-03-10 14:51 ` [PATCH 3/4] elf: align ET_DYN base to exec folio order for contpte mapping Usama Arif
2026-03-13 14:42 ` WANG Rui
2026-03-13 19:47 ` Usama Arif [this message]
2026-03-14 2:10 ` hev
2026-03-10 14:51 ` [PATCH 4/4] mm: align file-backed mmap to exec folio order in thp_get_unmapped_area Usama Arif
2026-03-14 3:47 ` WANG Rui
2026-03-13 13:20 ` [PATCH 0/4] arm64/mm: contpte-sized exec folios for 16K and 64K pages David Hildenbrand (Arm)
2026-03-13 19:59 ` Usama Arif
2026-03-16 16:06 ` David Hildenbrand (Arm)
2026-03-18 10:41 ` Usama Arif
2026-03-18 12:41 ` David Hildenbrand (Arm)
2026-03-13 16:33 ` Ryan Roberts
2026-03-13 20:55 ` Usama Arif
2026-03-18 10:52 ` Usama Arif
2026-03-19 7:40 ` David Hildenbrand (Arm)
2026-03-14 13:20 ` WANG Rui
2026-03-13 16:35 ` hev
2026-03-14 9:50 ` WANG Rui
2026-03-18 10:57 ` Usama Arif
2026-03-18 11:46 ` WANG Rui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d3f60289-3ea1-43ce-9271-58c8b79bf7a0@linux.dev \
--to=usama.arif@linux.dev \
--cc=Liam.Howlett@oracle.com \
--cc=ajd@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=apopple@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=brauner@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=kas@kernel.org \
--cc=kees@kernel.org \
--cc=kernel-team@meta.com \
--cc=kevin.brodsky@arm.com \
--cc=lance.yang@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=npache@redhat.com \
--cc=r@hev.cc \
--cc=rmclure@linux.ibm.com \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=viro@zeniv.linux.org.uk \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.