From: Hugh Dickins <hughd@google.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Hugh Dickins <hughd@google.com>, Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Huang Ying <ying.huang@intel.com>,
David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH 2/4] mm: migrate: convert numamigrate_isolate_page() to numamigrate_isolate_folio()
Date: Sat, 5 Aug 2023 22:04:48 -0700 (PDT) [thread overview]
Message-ID: <4b83ba15-9f1-812b-8620-1bd935262eaa@google.com> (raw)
In-Reply-To: <2f6c2ddb-b1a7-7152-bb7c-a5dcaf61ce36@huawei.com>
On Thu, 3 Aug 2023, Kefeng Wang wrote:
> On 2023/8/2 20:30, Matthew Wilcox wrote:
> > On Wed, Aug 02, 2023 at 05:53:44PM +0800, Kefeng Wang wrote:
> >> /* Do not migrate THP mapped by multiple processes */
> >> - if (PageTransHuge(page) && total_mapcount(page) > 1)
> >> + if (folio_test_pmd_mappable(folio) && folio_estimated_sharers(folio) >
> >> 1)
> >> return 0;
> >
> > I don't know if this is the right logic. We've willing to move folios
> > mapped by multiple processes, as long as they're smaller than PMD size,
> > but once they get to PMD size they're magical and can't be moved?
>
> It seems that the logical is introduced by commit 04fa5d6a6547 ("mm:
> migrate: check page_count of THP before migrating") and refactor by
> 340ef3902cf2 ("mm: numa: cleanup flow of transhuge page migration"),
>
>
> "Hugh Dickins pointed out that migrate_misplaced_transhuge_page() does
> not check page_count before migrating like base page migration and
> khugepage. He could not see why this was safe and he is right."
>
> For now, there is no migrate_misplaced_transhuge_page() and base/thp
> page migrate's path is unified, there is a check(for old/new kernel) in
> migrate_misplaced_page(),
Right, Mel's comment on safety above comes from a time when
migrate_misplaced_transhuge_page() went its own way, and so did not
reach the careful reference count checking found in (the now named)
folio_migrate_mapping(). If migrate_misplaced_page() is now using
the standard migrate_pages() for small pages and THPs, then there
should no longer be safety concerns.
>
> "Don't migrate file pages that are mapped in multiple processes
> with execute permissions as they are probably shared libraries."
>
> We could drop the above check in numamigrate_isolate_page(), but
> according to 04fa5d6a6547, maybe disable migrate page shared by
> multi-process during numa balance for both base/thp page.
I'm out of touch with the NUMA balancing preferences at present,
but think that you're probably right that it should aim to treat
folio mapped into multiple processes the same way for small and large
and THP (except, of course, that large and THP, with multiple PTEs in
the same process, can present more challenges to how to go about that).
Hugh
next prev parent reply other threads:[~2023-08-06 5:05 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 9:53 [PATCH 0/4] mm: migrate: more folio conversion Kefeng Wang
2023-08-02 9:53 ` [PATCH 1/4] mm: migrate: use a folio in add_page_for_migration() Kefeng Wang
2023-08-02 12:21 ` Matthew Wilcox
2023-08-03 7:13 ` Kefeng Wang
2023-08-03 12:30 ` Matthew Wilcox
2023-08-04 1:45 ` Kefeng Wang
2023-08-04 2:42 ` Zi Yan
2023-08-04 5:54 ` Kefeng Wang
2023-08-07 12:20 ` Kefeng Wang
2023-08-07 18:45 ` Zi Yan
2023-08-09 12:37 ` Kefeng Wang
2023-08-09 20:53 ` Mike Kravetz
2023-08-09 22:44 ` Mike Kravetz
2023-08-10 1:49 ` Kefeng Wang
2023-08-10 16:29 ` Mike Kravetz
2023-08-15 3:58 ` Huang, Ying
2023-08-15 21:12 ` Mike Kravetz
2023-08-16 0:50 ` Kefeng Wang
2023-08-15 3:56 ` Huang, Ying
2023-08-15 13:49 ` Zi Yan
2023-08-15 20:39 ` Huang, Ying
2023-08-02 9:53 ` [PATCH 2/4] mm: migrate: convert numamigrate_isolate_page() to numamigrate_isolate_folio() Kefeng Wang
2023-08-02 12:30 ` Matthew Wilcox
2023-08-03 7:08 ` Kefeng Wang
2023-08-06 5:04 ` Hugh Dickins [this message]
2023-08-02 9:53 ` [PATCH 3/4] mm: migrate: make migrate_misplaced_page() to take a folio Kefeng Wang
2023-08-02 9:53 ` [PATCH 4/4] mm: migrate: use __folio_test_movable() Kefeng Wang
2023-08-02 12:37 ` Matthew Wilcox
2023-08-02 12:38 ` David Hildenbrand
2023-08-02 11:47 ` [PATCH 0/4] mm: migrate: more folio conversion David Hildenbrand
2023-08-02 12:38 ` Kefeng Wang
2023-08-03 9:34 ` David Hildenbrand
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=4b83ba15-9f1-812b-8620-1bd935262eaa@google.com \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox