[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6ae6cd92-3ff4-7ed3-b337-a4dfe33da1c@google.com>
Date: Fri, 6 Aug 2021 13:27:27 -0700 (PDT)
From: Hugh Dickins <hughd@...gle.com>
To: Zi Yan <ziy@...dia.com>
cc: Vlastimil Babka <vbabka@...e.cz>,
David Hildenbrand <david@...hat.com>, linux-mm@...ck.org,
Matthew Wilcox <willy@...radead.org>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Mike Kravetz <mike.kravetz@...cle.com>,
Michal Hocko <mhocko@...nel.org>,
John Hubbard <jhubbard@...dia.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 00/15] Make MAX_ORDER adjustable as a kernel boot
time parameter.
On Fri, 6 Aug 2021, Zi Yan wrote:
>
> In addition, I would like to share more detail on my plan on supporting 1GB PUD THP.
> This patchset is the first step, enabling kernel to allocate 1GB pages, so that
> user can get 1GB THPs from ZONE_NORMAL and ZONE_MOVABLE without using
> alloc_contig_pages() or CMA allocator. The next step is to improve kernel memory
> fragmentation handling for pages up to MAX_ORDER, since currently pageblock size
> is still limited by memory section size. As a result, I will explore solutions
> like having additional larger pageblocks (up to MAX_ORDER) to counter memory
> fragmentation. I will discover what else needs to be solved as I gradually improve
> 1GB PUD THP support.
Sorry to be blunt, but let me state my opinion: 2MB THPs have given and
continue to give us more than enough trouble. Complicating the kernel's
mm further, just to allow 1GB THPs, seems a very bad tradeoff to me. I
understand that it's an appealing personal project; but for the sake of
of all the rest of us, please leave 1GB huge pages to hugetlbfs (until
the day when we are all using 2MB base pages).
Hugh
Powered by blists - more mailing lists