[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251228134454.89617c004a6625556f7ca9f3@linux-foundation.org>
Date: Sun, 28 Dec 2025 13:44:54 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: 李喆 <lizhe.67@...edance.com>
Cc: <muchun.song@...ux.dev>, <osalvador@...e.de>, <david@...nel.org>,
<fvdl@...gle.com>, <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
Ankur Arora <ankur.a.arora@...cle.com>
Subject: Re: [PATCH 0/8] Introduce a huge-page pre-zeroing mechanism
On Thu, 25 Dec 2025 16:20:51 +0800 李喆 <lizhe.67@...edance.com> wrote:
> This patchset is based on this commit[1]("mm/hugetlb: optionally
> pre-zero hugetlb pages").
>
> 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.
Ankur's contiguous page clearing work
(https://lkml.kernel.org/r/20251215204922.475324-1-ankur.a.arora@oracle.com)
will hopefully result in significant changes to the timing observations
in your changelogs?
Powered by blists - more mailing lists