[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z070YE81kJ-OnSX8@tiehlicka>
Date: Tue, 3 Dec 2024 13:06:56 +0100
From: Michal Hocko <mhocko@...e.com>
To: Frank van der Linden <fvdl@...gle.com>
Cc: Mateusz Guzik <mjguzik@...il.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
Subject: Re: [PATCH] mm/hugetlb: optionally pre-zero hugetlb pages
On Mon 02-12-24 14:50:49, Frank van der Linden wrote:
> On Mon, Dec 2, 2024 at 1:58 PM Mateusz Guzik <mjguzik@...il.com> wrote:
> > Any games with "background zeroing" are notoriously crappy and I would
> > argue one should exhaust other avenues before going there -- at the end
> > of the day the cost of zeroing will have to get paid.
>
> I understand that the concept of background prezeroing has been, and
> will be, met with some resistance. But, do you have any specific
> concerns with the patch I posted? It's pretty well isolated from the
> rest of the code, and optional.
The biggest concern I have is that the overhead is payed by everybody on
the system - it is considered to be a system overhead regardless only
part of the workload benefits from hugetlb pages. In other words the
workload using those pages is not accounted for the use completely.
If the startup latency is a real problem is there a way to workaround
that in the userspace by preallocating hugetlb pages ahead of time
before those VMs are launched and hand over already pre-allocated pages?
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists