From: Michal Hocko <mhocko@suse.com>
To: Frank van der Linden <fvdl@google.com>
Cc: Mateusz Guzik <mjguzik@gmail.com>,
linux-mm@kvack.org, akpm@linux-foundation.org,
Muchun Song <muchun.song@linux.dev>,
Miaohe Lin <linmiaohe@huawei.com>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@redhat.com>,
Peter Xu <peterx@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/hugetlb: optionally pre-zero hugetlb pages
Date: Tue, 3 Dec 2024 13:06:56 +0100 [thread overview]
Message-ID: <Z070YE81kJ-OnSX8@tiehlicka> (raw)
In-Reply-To: <CAPTztWbmkFisL7qnmAnre5hv=UD1E60P0hr_kXNyLoQFy9OoTA@mail.gmail.com>
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@gmail.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
next prev parent reply other threads:[~2024-12-03 12:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-02 20:20 Frank van der Linden
2024-12-02 21:58 ` Mateusz Guzik
2024-12-02 22:50 ` Frank van der Linden
2024-12-03 12:06 ` Michal Hocko [this message]
2024-12-03 12:17 ` David Hildenbrand
2024-12-03 14:26 ` Joao Martins
2024-12-03 15:57 ` Mateusz Guzik
2024-12-03 16:17 ` Mateusz Guzik
2024-12-03 16:21 ` Joao Martins
2024-12-03 18:43 ` Frank van der Linden
2024-12-03 20:15 ` Frank van der Linden
2024-12-03 14:02 ` Joao Martins
2024-12-04 0:06 ` Ankur Arora
2024-12-04 0:05 ` Ankur Arora
2024-12-04 17:01 ` Frank van der Linden
2024-12-04 19:57 ` Ankur Arora
2024-12-02 22:07 ` kernel test robot
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=Z070YE81kJ-OnSX8@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=fvdl@google.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mjguzik@gmail.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=peterx@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox