All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: John Hubbard <jhubbard@nvidia.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	akpm@linux-foundation.org
Cc: ying.huang@intel.com, willy@infradead.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] mm: support large folio numa balancing
Date: Tue, 14 Nov 2023 12:35:39 +0100	[thread overview]
Message-ID: <1b4de866-df27-46fa-81fa-6818a48d8cc1@redhat.com> (raw)
In-Reply-To: <00372b9e-6020-64b7-1381-e88d9744ed05@nvidia.com>

On 13.11.23 23:15, John Hubbard wrote:
> On 11/13/23 5:01 AM, Baolin Wang wrote:
>>
>>
>> On 11/13/2023 8:10 PM, Kefeng Wang wrote:
>>>
>>>
>>> On 2023/11/13 18:53, David Hildenbrand wrote:
>>>> 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@huawei.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.
> 
> To be honest, I'm still catching up on the approximate vs. exact
> sharers case. It wasn't clear to me why a precise sharers count
> is needed in order to do this. Perhaps the cost of making a wrong
> decision is considered just too high?

Good question, I didn't really look into the impact for the NUMA hinting 
case where we might end up not setting TNF_SHARED although it is shared. 
For other folio_estimate_sharers() users it's more obvious.

As a side note, it could have happened already in corner cases (e.g., 
concurrent page migration of a small folio).

If precision as documented in that commit is really required remains to 
be seen -- just wanted to spell it out.

-- 
Cheers,

David / dhildenb


  reply	other threads:[~2023-11-14 11:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-13 10:45 [RFC PATCH] mm: support large folio numa balancing Baolin Wang
2023-11-13 10:53 ` David Hildenbrand
2023-11-13 12:10   ` Kefeng Wang
2023-11-13 13:01     ` Baolin Wang
2023-11-13 22:15       ` John Hubbard
2023-11-14 11:35         ` David Hildenbrand [this message]
2023-11-14 13:12           ` Kefeng Wang
2023-11-13 12:59   ` Baolin Wang
2023-11-13 14:49     ` David Hildenbrand
2023-11-14 10:53       ` Baolin Wang
2023-11-14  1:12   ` Huang, Ying
2023-11-14 11:11     ` Baolin Wang
2023-11-15  2:58       ` Huang, Ying
2023-11-17 10:07         ` Mel Gorman
2023-11-17 10:13           ` Peter Zijlstra
2023-11-17 16:04             ` Mel Gorman
2023-11-20  8:01           ` Baolin Wang
2023-11-15 10:46 ` David Hildenbrand
2023-11-15 10:47   ` David Hildenbrand
2023-11-20  3:28     ` Baolin Wang

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=1b4de866-df27-46fa-81fa-6818a48d8cc1@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=wangkefeng.wang@huawei.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.