From: Minchan Kim <minchan@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: hughd@google.com, kirill@shutemov.name, linux-mm <linux-mm@kvack.org>
Subject: Re: THP handling with driver compound page on fault
Date: Fri, 29 Jan 2021 18:40:50 -0800 [thread overview]
Message-ID: <YBTHMttv67Nb/Lef@google.com> (raw)
In-Reply-To: <20210130020911.GG308988@casper.infradead.org>
On Sat, Jan 30, 2021 at 02:09:11AM +0000, Matthew Wilcox wrote:
> On Fri, Jan 29, 2021 at 05:49:11PM -0800, Minchan Kim wrote:
> > On Sat, Jan 30, 2021 at 01:28:44AM +0000, Matthew Wilcox wrote:
> > > On Fri, Jan 29, 2021 at 05:22:24PM -0800, Minchan Kim wrote:
> > > > Hi Mattew,
> > > >
> > > > On Sat, Jan 30, 2021 at 01:00:02AM +0000, Matthew Wilcox wrote:
> > > > > On Fri, Jan 29, 2021 at 04:13:07PM -0800, Minchan Kim wrote:
> > > > > > A custom driver overrides (vm_operations_struct.fault) and map their
> > > > > > compound page(__GFP_COMP) to page table on userprocess on demand.
> > > > >
> > > > > You're looking to backport:
> > > > >
> > > > > commit d01ac3c35214ce362f50cada37cb7bab8c801896
> > > > > Author: Matthew Wilcox (Oracle) <willy@infradead.org>
> > > > > Date: Thu Oct 15 20:05:26 2020 -0700
> > > > >
> > > > > mm/memory: remove page fault assumption of compound page size
> > > > >
> > > >
> > > > I guess you meant the check below.
> > > >
> > > > if (compound_order(page) != HPAGE_PMD_ORDER)
> > > >
> > > > What happens if driver allcoated HPAGE_PMD_ORDER size?
> > >
> > > ... then it should be fine to map it with a PMD entry?
> >
> > I don't think so because following logic assumes it's THP page,
> > for example, page_add_file_rmap, count_vm_event(THP_FILE_MAPPED)
> > in do_set_pmd.
> >
> > Isn't it bug?
>
> Clearly nobody's actually tested it, but I think in principle, if a
> device driver returns a PMD sized page (and it's appropriately aligned),
> it should be mapped with a PMD entry.
Okay, then you mean d01ac3c35214ce362f50cada37cb7bab8c801896 will
fix the corruption for every-order driver compound page mapping.
I have no idea it's worth to solve THP_FILE_MAPPED misaccounting
problem but it doesn't matter for my case, at least.
Thanks for the quick answer, Matthew.
prev parent reply other threads:[~2021-01-30 2:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-30 0:13 THP handling with driver compound page on fault Minchan Kim
2021-01-30 1:00 ` Matthew Wilcox
2021-01-30 1:22 ` Minchan Kim
2021-01-30 1:28 ` Matthew Wilcox
2021-01-30 1:49 ` Minchan Kim
2021-01-30 2:09 ` Matthew Wilcox
2021-01-30 2:40 ` Minchan Kim [this message]
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=YBTHMttv67Nb/Lef@google.com \
--to=minchan@kernel.org \
--cc=hughd@google.com \
--cc=kirill@shutemov.name \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.