Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: qXA0Cy5Sxat0HlfJSXHh9gid2sfZE9wDO326BmQtwTQB+2Q+8CbzsinEgj5BrSrTPUQg8OT5b6
 N9jAMKFK1F9g==
IronPort-SDR: 1pfPbXhjlYYReGkPxq6HfP4+S3mzqWZg9G55ESeGOM9vhqkGCJ7BYRc35RiXXmWynnugSAJ6uM
 atnC5MlIfazg==
From:   "Huang, Ying" <ying.huang@intel.com>
To:     "Zi Yan" <ziy@nvidia.com>
Cc:     Yang Shi <shy828301@gmail.com>, <mgorman@suse.de>,
        <kirill.shutemov@linux.intel.com>, <mhocko@suse.com>,
        <hughd@google.com>, <gerald.schaefer@linux.ibm.com>,
        <hca@linux.ibm.com>, <gor@linux.ibm.com>, <borntraeger@de.ibm.com>,
        <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
        <linux-s390@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [v2 PATCH 6/7] mm: migrate: check mapcount for THP instead of
 ref count
References: <20210413212416.3273-1-shy828301@gmail.com>
        <20210413212416.3273-7-shy828301@gmail.com>
        <87k0p5sh7h.fsf@yhuang6-desk1.ccr.corp.intel.com>
        <6297AD92-8D0E-4BEC-8E1F-5C5AC32FA128@nvidia.com>
Date:   Thu, 15 Apr 2021 14:45:54 +0800
In-Reply-To: <6297AD92-8D0E-4BEC-8E1F-5C5AC32FA128@nvidia.com> (Zi Yan's
        message of "Wed, 14 Apr 2021 11:02:58 -0400")
Message-ID: <87fszsoxjx.fsf@yhuang6-desk1.ccr.corp.intel.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=ascii
Precedence: bulk

"Zi Yan" <ziy@nvidia.com> writes:

> On 13 Apr 2021, at 23:00, Huang, Ying wrote:
>
>> Yang Shi <shy828301@gmail.com> writes:
>>
>>> The generic migration path will check refcount, so no need check refcount here.
>>> But the old code actually prevents from migrating shared THP (mapped by multiple
>>> processes), so bail out early if mapcount is > 1 to keep the behavior.
>>
>> What prevents us from migrating shared THP?  If no, why not just remove
>> the old refcount checking?
>
> If two or more processes are in different NUMA nodes, a THP shared by them can be
> migrated back and forth between NUMA nodes, which is quite costly. Unless we have
> a better way of figuring out a good location for such pages to reduce the number
> of migration, it might be better not to move them, right?
>

Some mechanism has been provided in should_numa_migrate_memory() to
identify the shared pages from the private pages.  Do you find it
doesn't work well in some situations?

The multiple threads in one process which run on different NUMA nodes
may share pages too.  So it isn't a good solution to exclude pages
shared by multiple processes.

Best Regards,
Huang, Ying