Received-SPF: pass (google.com: domain of linux-kernel+bounces-122264-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: "Huang, Ying" <ying.huang@intel.com>
To: David Hildenbrand <david@redhat.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>,  akpm@linux-foundation.org,
  mgorman@techsingularity.net,  wangkefeng.wang@huawei.com,
  jhubbard@nvidia.com,  21cnbao@gmail.com,  ryan.roberts@arm.com,
  linux-mm@kvack.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] mm: support multi-size THP numa balancing
In-Reply-To: <6248d6fb-b982-4ebd-93a9-7750cc4a5039@redhat.com> (David
	Hildenbrand's message of "Wed, 27 Mar 2024 09:47:24 +0100")
References: <cover.1711453317.git.baolin.wang@linux.alibaba.com>
	<dee4268f1797f31c6bb6bdab30f8ad3df9053d3d.1711453317.git.baolin.wang@linux.alibaba.com>
	<87cyrgo2ez.fsf@yhuang6-desk2.ccr.corp.intel.com>
	<bc671388-f398-4776-af15-c144f2c39d78@linux.alibaba.com>
	<87edbwm6fh.fsf@yhuang6-desk2.ccr.corp.intel.com>
	<6248d6fb-b982-4ebd-93a9-7750cc4a5039@redhat.com>
Date: Thu, 28 Mar 2024 09:09:46 +0800
Message-ID: <8734sbmaat.fsf@yhuang6-desk2.ccr.corp.intel.com>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=ascii

David Hildenbrand <david@redhat.com> writes:

> On 27.03.24 09:21, Huang, Ying wrote:
>> Baolin Wang <baolin.wang@linux.alibaba.com> writes:
>> 
>>> On 2024/3/27 10:04, Huang, Ying wrote:
>>>> Baolin Wang <baolin.wang@linux.alibaba.com> writes:
>>>>
>>>>> Now the anonymous page allocation already supports multi-size THP (mTHP),
>>>>> but the numa balancing still prohibits mTHP migration even though it is an
>>>>> exclusive mapping, which is unreasonable.
>>>>>
>>>>> Allow scanning mTHP:
>>>>> Commit 859d4adc3415 ("mm: numa: do not trap faults on shared data section
>>>>> pages") skips shared CoW pages' NUMA page migration to avoid shared data
>>>>> segment migration. In addition, commit 80d47f5de5e3 ("mm: don't try to
>>>>> NUMA-migrate COW pages that have other uses") change to use page_count()
>>>>> to avoid GUP pages migration, that will also skip the mTHP numa scaning.
>>>>> Theoretically, we can use folio_maybe_dma_pinned() to detect the GUP
>>>>> issue, although there is still a GUP race, the issue seems to have been
>>>>> resolved by commit 80d47f5de5e3. Meanwhile, use the folio_likely_mapped_shared()
>>>>> to skip shared CoW pages though this is not a precise sharers count. To
>>>>> check if the folio is shared, ideally we want to make sure every page is
>>>>> mapped to the same process, but doing that seems expensive and using
>>>>> the estimated mapcount seems can work when running autonuma benchmark.
>>>> Because now we can deal with shared mTHP, it appears even possible
>>>> to
>>>> remove folio_likely_mapped_shared() check?
>>>
>>> IMO, the issue solved by commit 859d4adc3415 is about shared CoW
>>> mapping, and I prefer to measure it in another patch:)
>> I mean we can deal with shared mTHP (by multiple threads or multiple
>> processes) with this patch.  Right?
>
> It's independent of the folio order. We don't want to mess with shared COW pages, see
>
> commit 859d4adc3415a64ccb8b0c50dc4e3a888dcb5805
> Author: Henry Willard <henry.willard@oracle.com>
> Date:   Wed Jan 31 16:21:07 2018 -0800
>
>     mm: numa: do not trap faults on shared data section pages.
>          Workloads consisting of a large number of processes running
>         the same
>     program with a very large shared data segment may experience performance
>     problems when numa balancing attempts to migrate the shared cow pages.
>     This manifests itself with many processes or tasks in
>     TASK_UNINTERRUPTIBLE state waiting for the shared pages to be migrated.
> ...
>
> that introduced this handling.

Sorry, I misunderstood your words.

--
Best Regards,
Huang, Ying