linux-kernel - Re: [v2 PATCH 6/7] mm: migrate: check mapcount for THP instead of ref count

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87fszsoxjx.fsf@yhuang6-desk1.ccr.corp.intel.com>
Date:   Thu, 15 Apr 2021 14:45:54 +0800
From:   "Huang, Ying" <ying.huang@...el.com>
To:     "Zi Yan" <ziy@...dia.com>
Cc:     Yang Shi <shy828301@...il.com>, <mgorman@...e.de>,
        <kirill.shutemov@...ux.intel.com>, <mhocko@...e.com>,
        <hughd@...gle.com>, <gerald.schaefer@...ux.ibm.com>,
        <hca@...ux.ibm.com>, <gor@...ux.ibm.com>, <borntraeger@...ibm.com>,
        <akpm@...ux-foundation.org>, <linux-mm@...ck.org>,
        <linux-s390@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [v2 PATCH 6/7] mm: migrate: check mapcount for THP instead of
 ref count

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

> On 13 Apr 2021, at 23:00, Huang, Ying wrote:
>
>> Yang Shi <shy828301@...il.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