Message-ID: <72320F9D-9B6A-4ABA-9B18-E59B8382A262@nvidia.com>
Date: Mon, 29 Jul 2024 21:26:21 -0400
From: Zi Yan <ziy@...dia.com>
To: Nico Pache <npache@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
 David Hildenbrand <david@...hat.com>, Matthew Wilcox <willy@...radead.org>,
 Barry Song <baohua@...nel.org>, Ryan Roberts <ryan.roberts@....com>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>,
 Lance Yang <ioworker0@...il.com>, Peter Xu <peterx@...hat.com>,
 Rafael Aquini <aquini@...hat.com>, Andrea Arcangeli <aarcange@...hat.com>,
 Jonathan Corbet <corbet@....net>,
 "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [RFC 0/2] mm: introduce THP deferred setting

+Kirill

On 29 Jul 2024, at 18:27, Nico Pache wrote:

> We've seen cases were customers switching from RHEL7 to RHEL8 see a
> significant increase in the memory footprint for the same workloads.
>
> Through our investigations we found that a large contributing factor to
> the increase in RSS was an increase in THP usage.

Any knob is changed from RHEL7 to RHEL8 to cause more THP usage?

>
> For workloads like MySQL, or when using allocators like jemalloc, it is
> often recommended to set /transparent_hugepages/enabled=never. This is
> in part due to performance degradations and increased memory waste.
>
> This series introduces enabled=defer, this setting acts as a middle
> ground between always and madvise. If the mapping is MADV_HUGEPAGE, the
> page fault handler will act normally, making a hugepage if possible. If
> the allocation is not MADV_HUGEPAGE, then the page fault handler will
> default to the base size allocation. The caveat is that khugepaged can
> still operate on pages thats not MADV_HUGEPAGE.

Why? If user does not explicitly want huge page, why bother providing huge
pages? Wouldn't it increase memory footprint?

>
> This allows for two things... one, applications specifically designed to
> use hugepages will get them, and two, applications that don't use
> hugepages can still benefit from them without aggressively inserting
> THPs at every possible chance. This curbs the memory waste, and defers
> the use of hugepages to khugepaged. Khugepaged can then scan the memory
> for eligible collapsing.

khugepaged would replace application memory with huge pages without specific
goal. Why not use a user space agent with process_madvise() to collapse
huge pages? Admin might have more knobs to tweak than khugepaged.

>
> Admins may want to lower max_ptes_none, if not, khugepaged may
> aggressively collapse single allocations into hugepages.
>
> RFC note
> ==========
> Im not sure if im missing anything related to the mTHP
> changes. I think now that we have hugepage_pmd_enabled in
> commit 00f58104202c ("mm: fix khugepaged activation policy") everything
> should work as expected.
>
> Nico Pache (2):
>   mm: defer THP insertion to khugepaged
>   mm: document transparent_hugepage=defer usage
>
>  Documentation/admin-guide/mm/transhuge.rst | 18 ++++++++++---
>  include/linux/huge_mm.h                    | 15 +++++++++--
>  mm/huge_memory.c                           | 31 +++++++++++++++++++---
>  3 files changed, 55 insertions(+), 9 deletions(-)
>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: David Hildenbrand <david@...hat.com>
> Cc: Matthew Wilcox <willy@...radead.org>
> Cc: Barry Song <baohua@...nel.org>
> Cc: Ryan Roberts <ryan.roberts@....com>
> Cc: Baolin Wang <baolin.wang@...ux.alibaba.com>
> Cc: Lance Yang <ioworker0@...il.com>
> Cc: Peter Xu <peterx@...hat.com>
> Cc: Zi Yan <ziy@...dia.com>
> Cc: Rafael Aquini <aquini@...hat.com>
> Cc: Andrea Arcangeli <aarcange@...hat.com>
> Cc: Jonathan Corbet <corbet@....net>
> -- 
> 2.45.2

--
Best Regards,
Yan, Zi

Download attachment "signature.asc" of type "application/pgp-signature" (855 bytes)

Powered by blists - more mailing lists