From: Matthew Wilcox <willy@infradead.org>
To: "Yin, Fengwei" <fengwei.yin@intel.com>
Cc: linux-mm@kvack.org, dave.hansen@intel.com, tim.c.chen@intel.com,
ying.huang@intel.com
Subject: Re: [RFC PATCH 2/2] rmap: remove parameter 'compound' from foeio_add_file_rmap_range()
Date: Tue, 7 Feb 2023 05:03:16 +0000 [thread overview]
Message-ID: <Y+HblAN5bM1uYD2f@casper.infradead.org> (raw)
In-Reply-To: <a015e10d-766c-a71a-fac0-69f9aa4e2643@intel.com>
On Tue, Feb 07, 2023 at 10:44:10AM +0800, Yin, Fengwei wrote:
> On 2/7/2023 12:50 AM, Matthew Wilcox wrote:
> > On Mon, Feb 06, 2023 at 11:30:49PM +0800, Yin Fengwei wrote:
> >> Remove parameter 'compound' from folio_add_file_rmap_range().
> >>
> >> The parameter nr_pages is checked whether same as folio page
> >> numbers to know whether it's entire folio operation.
> >
> > We can't do this yet. Even if a folio is large enough to be PMD mapped,
> > it may have been mapped askew (or its PMD mapping may have been split).
> > We still need the caller to tell us whether it's been mapped with
> > a PMD or with PTEs.
> OK. My understand is that the info about PMD mapped is only for
> statistic update. Maybe move the PMD mapped statistic to caller.
Alas, no. That 'compound' parameter really means "to be mapped by a
PMD". And we need to change all of add_file, add_anon and remove
at the same time, otherwise we don't know which counter to inc/dec
in page_remove_rmap().
> Another thing I am not sure whether it's worthy:
> What about maintaining total mapcount for folio? So we don't need to
> query each page mapcount to know it. So we can use "total_mapoucnt >
> mapped" to know whether the folio has at least one page mapped more
> than once.
>
> The payback is that we need update total mapcount when map/unmap
> the folio.
Right, there are lots of mapcounts we _could_ maintain. The important
thing to understand is who wants to know what. As I see it, there are
three important things we need to know:
1. Is any page in this folio mapped?
(everywhere that calls folio_mapped() or page_mapped())
2. Is any page in this folio mapped more than once?
(some madvise calls, migration)
3. How many refcounts does the mapcount account for?
(splitting, compaction)
Some of the things we use mapcount for today I consider to be unimportant.
For example, shrink_folio_list() checks to see if there are any PMD
mappings and will split it if there are not. This doesn't fit my vision
of how the VM should work; I believe we should swap the entire folio
out as a single unit.
So I don't really want to think about maintaining total_mapcount,
I want the concept of total_mapcount to go away and just have a single
mapcount for each folio, instead of this complex mismash of
entire_mapcount, mapcount and total_mapcount.
next prev parent reply other threads:[~2023-02-07 5:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-06 15:30 [RFC PATCH 0/2] remove parameter 'compound' of add_file_rmap Yin Fengwei
2023-02-06 15:30 ` [RFC PATCH 1/2] rmap: Add function to handle entire folio rmap removing Yin Fengwei
2023-02-06 15:30 ` [RFC PATCH 2/2] rmap: remove parameter 'compound' from foeio_add_file_rmap_range() Yin Fengwei
2023-02-06 16:50 ` Matthew Wilcox
2023-02-07 2:44 ` Yin, Fengwei
2023-02-07 5:03 ` Matthew Wilcox [this message]
2023-02-07 5:35 ` Yin, Fengwei
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=Y+HblAN5bM1uYD2f@casper.infradead.org \
--to=willy@infradead.org \
--cc=dave.hansen@intel.com \
--cc=fengwei.yin@intel.com \
--cc=linux-mm@kvack.org \
--cc=tim.c.chen@intel.com \
--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