linux-kernel - Re: [PATCH] mm/hugetlb: optionally pre-zero hugetlb pages

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: <87iks0cnvy.fsf@oracle.com>
Date: Tue, 03 Dec 2024 16:06:41 -0800
From: Ankur Arora <ankur.a.arora@...cle.com>
To: Joao Martins <joao.m.martins@...cle.com>
Cc: Mateusz Guzik <mjguzik@...il.com>, Frank van der Linden
 <fvdl@...gle.com>,
        linux-mm@...ck.org, akpm@...ux-foundation.org,
        Muchun
 Song <muchun.song@...ux.dev>,
        Miaohe Lin <linmiaohe@...wei.com>, Oscar
 Salvador <osalvador@...e.de>,
        David Hildenbrand <david@...hat.com>, Peter
 Xu <peterx@...hat.com>,
        linux-kernel@...r.kernel.org, Ankur Arora
 <ankur.a.arora@...cle.com>
Subject: Re: [PATCH] mm/hugetlb: optionally pre-zero hugetlb pages


Joao Martins <joao.m.martins@...cle.com> writes:

> On 02/12/2024 21:58, Mateusz Guzik wrote:
>> On Mon, Dec 02, 2024 at 08:20:58PM +0000, Frank van der Linden wrote:
>>> Fresh hugetlb pages are zeroed out when they are faulted in,
>>> just like with all other page types. This can take up a good
>>> amount of time for larger page sizes (e.g. around 40
>>> milliseconds for a 1G page on a recent AMD-based system).
>>>
>>> This normally isn't a problem, since hugetlb pages are typically
>>> mapped by the application for a long time, and the initial
>>> delay when touching them isn't much of an issue.
>>>
>>> However, there are some use cases where a large number of hugetlb
>>> pages are touched when an application (such as a VM backed by these
>>> pages) starts. For 256 1G pages and 40ms per page, this would take
>>> 10 seconds, a noticeable delay.
>>
>> The current huge page zeroing code is not that great to begin with.
>>
>> There was a patchset posted some time ago to remedy at least some of it:
>> https://lore.kernel.org/all/20230830184958.2333078-1-ankur.a.arora@oracle.com/
>>
>> but it apparently fell through the cracks.
>>
>
> It didn't fell through the cracks for sure
>
> Just had a detour into preempt=auto before resuming the main work. But that
> seems to be done in the last merge window with the lazy preempt stuff. I think
> Ankur was planning on following that series above soon-ish.
>
> Adding him here, such that he keeps me honest :)

Thanks for Ccing Joao.

--
ankur