linux-kernel - Re: [PATCH] mm: limit THP alignment – performance gain observed in AI inference workloads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <afe95bb0-185b-4c4a-ae41-e02457422cc3@arm.com>
Date: Tue, 1 Jul 2025 12:28:37 +0530
From: Dev Jain <dev.jain@....com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: siddhartha@...ip.in, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 mgorman@...e.de, Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH] mm: limit THP alignment – performance gain observed in AI inference workloads


On 01/07/25 12:20 pm, Lorenzo Stoakes wrote:
> On Tue, Jul 01, 2025 at 12:00:21PM +0530, Dev Jain wrote:
>> On 01/07/25 11:23 am, Lorenzo Stoakes wrote:
>>> On Tue, Jul 01, 2025 at 11:15:25AM +0530, Dev Jain wrote:
>>>> Sorry I am not following, don't know in detail about the VMA merge stuff.
>>>> Are you saying the after the patch, the VMAs will eventually get merged?
>>>> Is it possible in the kernel to get a merge in the "future"; as I understand
>>>> it only happens at mmap() time?
>>>>
>>>> Suppose before the patch, you have two consecutive VMAs between (PMD, 2*PMD) size.
>>>> If they are able to get merged after the patch, why won't they be merged before the patch,
>>>> since the VMA characteristics are the same?
>>>>
>>>>
>>> Rik's patch aligned each to 2 MiB boundary. So you'd get gaps:
>>>
>>>
>>>     0            2MB                 4MB           6MB                      8MB          10MB
>>>     |-------------.------|            |-------------.------|                 |-------------.------|
>>>     |             .      |		 |             .      |                 |             .      |
>>>     |             .      |		 |             .      |                 |             .      |
>>>     |-------------.------|		 |-------------.------|                 |-------------.------|
>>>       huge mapped  4k m'd
>> The effort to draw this is appreciated!
>>
>> I understood the alignment, what I am asking is this:
>>
>> In __get_unmapped_area(), we will return a THP-aligned addr from
>> thp_get_unmapped_area_vmflags(). Now for the diagram you have
>> drawn, suppose that before the patch, we first mmap() the
>> 8MB-start chunk. Then we mmap the 4MB start chunk.
>> We go to __mmap_region(), and we see that the 8MB-start chunk
>> has mergeable characteristics, so we merge. So the gap goes away?
> No because there's a gap, we only merge immedaitely adjacent VMAs. And obviously
> gaps mean page tables wouldn't be adjacent either...

Ah shoot. That is prev->vm_end == vmg->start in can_vma_merge_left(). Thanks.

>
> The get_unmmaped_area() would have otherwise given adjacent mappings. Vlasta's
> patch means in this case we no longer bother trying to align these because their
> _length_ isn't PMD aligned.