[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <606d2d7a-d937-4ffe-a6f2-dfe3ae5a0c91@redhat.com>
Date: Mon, 13 Nov 2023 11:53:12 +0100
From: David Hildenbrand <david@...hat.com>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>,
akpm@...ux-foundation.org
Cc: ying.huang@...el.com, wangkefeng.wang@...wei.com,
willy@...radead.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, John Hubbard <jhubbard@...dia.com>
Subject: Re: [RFC PATCH] mm: support large folio numa balancing
On 13.11.23 11:45, Baolin Wang wrote:
> Currently, the file pages already support large folio, and supporting for
> anonymous pages is also under discussion[1]. Moreover, the numa balancing
> code are converted to use a folio by previous thread[2], and the migrate_pages
> function also already supports the large folio migration.
>
> So now I did not see any reason to continue restricting NUMA balancing for
> large folio.
I recall John wanted to look into that. CCing him.
I'll note that the "head page mapcount" heuristic to detect sharers will
now strike on the PTE path and make us believe that a large folios is
exclusive, although it isn't.
As spelled out in the commit you are referencing:
commit 6695cf68b15c215d33b8add64c33e01e3cbe236c
Author: Kefeng Wang <wangkefeng.wang@...wei.com>
Date: Thu Sep 21 15:44:14 2023 +0800
mm: memory: use a folio in do_numa_page()
Numa balancing only try to migrate non-compound page in do_numa_page(),
use a folio in it to save several compound_head calls, note we use
folio_estimated_sharers(), it is enough to check the folio sharers since
only normal page is handled, if large folio numa balancing is supported, a
precise folio sharers check would be used, no functional change intended.
I'll send WIP patches for one approach that can improve the situation soonish.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists