From: Matthew Wilcox <willy@infradead.org>
To: Zi Yan <ziy@nvidia.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/3] mm/migrate: Add folio_migrate_mapping
Date: Tue, 11 May 2021 23:32:42 +0100 [thread overview]
Message-ID: <YJsGCu+zvqSR7WV1@casper.infradead.org> (raw)
In-Reply-To: <DD640D43-3101-4291-9882-57A89C74866E@nvidia.com>
On Tue, May 11, 2021 at 06:04:21PM -0400, Zi Yan wrote:
> On 10 May 2021, at 19:23, Matthew Wilcox (Oracle) wrote:
> > +++ b/mm/migrate.c
> > @@ -355,7 +355,7 @@ static int expected_page_refs(struct address_space *mapping, struct page *page)
> > */
> > expected_count += is_device_private_page(page);
> > if (mapping)
> > - expected_count += thp_nr_pages(page) + page_has_private(page);
> > + expected_count += compound_nr(page) + page_has_private(page);
>
> Why this change? Is it because you are passing folio->page to expected_page_refs() below
> and the nr_pages for the folio should be checked with folio_nr_pages() which just returns
> compound_nr()?
>
> The change seems to imply that folio can be compound page and migrated even when THP is
> disabled. Is it the case or something else?
That's exactly right.
In general, I don't like to pass &folio->page to functions, but this one
might be handling device private pages (apparently), and they have bogus
refcounts, so devmap pages are explicitly disallowed from being folios
until the refcount problem gets fixed.
next prev parent reply other threads:[~2021-05-11 22:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 23:23 [RFC PATCH 0/3] Folio migration Matthew Wilcox (Oracle)
2021-05-10 23:23 ` [RFC PATCH 1/3] mm/migrate: Add folio_migrate_mapping Matthew Wilcox (Oracle)
2021-05-11 22:04 ` Zi Yan
2021-05-11 22:32 ` Matthew Wilcox [this message]
2021-05-10 23:23 ` [RFC PATCH 2/3] mm/migrate: Add folio_migrate_flags Matthew Wilcox (Oracle)
2021-05-10 23:23 ` [RFC PATCH 3/3] mm/migrate: Add folio_migrate_copy Matthew Wilcox (Oracle)
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=YJsGCu+zvqSR7WV1@casper.infradead.org \
--to=willy@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ziy@nvidia.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;
as well as URLs for NNTP newsgroup(s).