From: Joao Martins <email@example.com>
To: Jason Gunthorpe <firstname.lastname@example.org>, Dan Williams <email@example.com>
Cc: "Matthew Wilcox" <firstname.lastname@example.org>,
"Alex Sierra" <email@example.com>,
"Andrew Morton" <firstname.lastname@example.org>,
"Kuehling, Felix" <Felix.Kuehling@amd.com>,
"Linux MM" <email@example.com>,
"Ralph Campbell" <firstname.lastname@example.org>,
"amd-gfx list" <email@example.com>,
"Maling list - DRI developers" <firstname.lastname@example.org>,
"Christoph Hellwig" <email@example.com>,
"Jérôme Glisse" <firstname.lastname@example.org>,
"Alistair Popple" <email@example.com>,
"Vishal Verma" <firstname.lastname@example.org>,
"Dave Jiang" <email@example.com>,
"Linux NVDIMM" <firstname.lastname@example.org>,
"David Hildenbrand" <email@example.com>
Subject: Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount
Date: Tue, 19 Oct 2021 16:13:34 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 10/19/21 00:06, Jason Gunthorpe wrote:
> On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
>>> device-dax uses PUD, along with TTM, they are the only places. I'm not
>>> sure TTM is a real place though.
>> I was setting device-dax aside because it can use Joao's changes to
>> get compound-page support.
> Ideally, but that ideas in that patch series have been floating around
> for a long time now..
The current status of the series misses a Rb on patches 6,7,10,12-14.
Well, patch 8 too should now drop its tag, considering the latest
If it helps moving things forward I could split my series further into:
1) the compound page introduction (patches 1-7) of my aforementioned series
2) vmemmap deduplication for memory gains (patches 9-14)
3) gup improvements (patch 8 and gup-slow improvements)
The reason being that item 1) is the the main dependency listed below.
And allows 2) and 3) to be parallelized. FWIW, it is almost fully reviewed
by Dan (as of v3->v4). For (1) patches 6 & 7 are on changes to
device-dax subsystem (drivers/dax/*) which still needs his Ack.
>>> Here I imagine the thing that creates the pgmap would specify the
>>> policy it wants. In most cases the policy is tightly coupled to what
>>> the free function in the the provided dev_pagemap_ops does..
>> The thing that creates the pgmap is the device-driver, and
>> device-driver does not implement truncate or reclaim. It's not until
>> the FS mounts that the pgmap needs to start enforcing pin lifetime
> I am explaining this wrong, the immediate need is really 'should
> foll_longterm fail fast-gup to the slow path' and something like the
> nvdimm driver can just set that to 1 and rely on VMA flags to control
> what the slow path does - as is today.
> It is not as elegant as more flags in the pgmap, but it would get the
> job done with minimal fuss.
> Might be nice to either rely fully on VMA flags or fully on pgmap
> holder flags for FOLL_LONGTERM?
Whats the benefit between preventing longterm at start
versus only after mounting the filesystem? Or is the intended future purpose
to pass more context into an holder potential future callback e.g. nack longterm
pins on a page basis?
Maybe we can start by at least not add any flags and just prevent
FOLL_LONGTERM on fsdax -- which I guess was the original purpose of
commit 7af75561e171 ("mm/gup: add FOLL_LONGTERM capability to GUP fast").
This patch (which I can formally send) has a sketch of that (below scissors mark):
It uses pgmap->type rather than adding further fields into pgmap, given this
restriction applies only to fsdax.
... and then we could improve devmap_longterm_available(pgmap) to look at the
holder::flags or pgmap::flags should we decide that an explicit flags is required
from holder/pgmap .. as a further improvement?
next prev parent reply other threads:[~2021-10-19 15:14 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-14 15:39 [PATCH v1 0/2] mm: remove extra ZONE_DEVICE struct page refcount Alex Sierra
2021-10-14 15:39 ` [PATCH v1 1/2] ext4/xfs: add page refcount helper Alex Sierra
2021-10-14 16:25 ` Jason Gunthorpe
2021-10-14 16:40 ` Matthew Wilcox
2021-10-14 15:39 ` [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount Alex Sierra
2021-10-14 16:52 ` Matthew Wilcox
2021-10-14 17:06 ` Jason Gunthorpe
2021-10-14 17:35 ` Ralph Campbell
2021-10-14 18:01 ` Jason Gunthorpe
2021-10-14 20:57 ` Ralph Campbell
2021-10-15 3:45 ` Sierra Guiza, Alejandro (Alex)
2021-10-15 11:06 ` Jason Gunthorpe
2021-10-14 18:43 ` Matthew Wilcox
2021-10-14 19:01 ` Dan Williams
2021-10-14 23:06 ` Jason Gunthorpe
2021-10-15 1:37 ` Dan Williams
2021-10-16 15:44 ` Jason Gunthorpe
2021-10-16 16:39 ` Matthew Wilcox
2021-10-17 18:20 ` Dan Williams
2021-10-17 18:35 ` Dan Williams
2021-10-18 18:25 ` Jason Gunthorpe
2021-10-18 19:37 ` Dan Williams
2021-10-18 23:06 ` Jason Gunthorpe
2021-10-19 15:13 ` Joao Martins [this message]
2021-10-19 16:01 ` Jason Gunthorpe
2021-10-19 19:21 ` Dan Williams
2021-10-20 17:06 ` Joao Martins
2021-10-20 17:12 ` Dan Williams
2021-10-20 18:51 ` Joao Martins
2021-11-15 19:33 [PATCH v1 0/2] Remove extra ZONE_DEVICE " Alex Sierra
2021-11-15 19:33 ` [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct " Alex Sierra
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).