[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <A8E67D62-8857-4A99-B6CE-5144D857EF0F@nvidia.com>
Date: Wed, 09 Oct 2024 10:21:00 -0400
From: Zi Yan <ziy@...dia.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>
Cc: linux-mm@...ck.org, "Matthew Wilcox (Oracle)" <willy@...radead.org>,
Ryan Roberts <ryan.roberts@....com>, Hugh Dickins <hughd@...gle.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
David Hildenbrand <david@...hat.com>, Yang Shi <yang@...amperecomputing.com>,
Miaohe Lin <linmiaohe@...wei.com>, Kefeng Wang <wangkefeng.wang@...wei.com>,
Yu Zhao <yuzhao@...gle.com>, John Hubbard <jhubbard@...dia.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/1] Buddy allocator like folio split
On 9 Oct 2024, at 5:54, Kirill A. Shutemov wrote:
> On Tue, Oct 08, 2024 at 06:37:47PM -0400, Zi Yan wrote:
>> mm/huge_memory.c | 648 ++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 647 insertions(+), 1 deletion(-)
>
> The idea is sane, but I think it would require a lot more ground work
> before getting it upstream. I don't think we can afford two parallel split
> implementations. folio_split() and split_huge_page*() should share the same
> implementation internally. Otherwise it is going to be pain to maintain
> them in-sync.
The goal is to replace split_huge_page*() with folio_split(). But for now,
split_huge_page*() is still needed for swap cached anon folios and shmem.
And this might take quite a while until we have a better swap system.
I think it is possible to use the same internal implementation
for both folio_split() and split_huge_page*(). I can give it a try in
the next version.
--
Best Regards,
Yan, Zi
Download attachment "signature.asc" of type "application/pgp-signature" (855 bytes)
Powered by blists - more mailing lists