On Wed, Oct 20, 2021 at 10:09 AM Joao Martins [off-list ref] wrote:

On 10/19/21 20:21, Dan Williams wrote:

quoted

On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe [off-list ref] wrote:

quoted

On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:

quoted

On 10/19/21 00:06, Jason Gunthorpe wrote:

quoted

On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:

quoted

quoted

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
discussion.

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)

I would split it, yes..

I think we can see a general consensus that making compound_head/etc
work consistently with how THP uses it will provide value and
opportunity for optimization going forward.

I'll go do that. Meanwhile, I'll wait a couple days for Dan to review the
dax subsystem patches (6 & 7), or otherwise send them over.

quoted

quoted

quoted

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?

I understood Dan's remark that the device-dax path allows
FOLL_LONGTERM and the FSDAX path does not ?

Which, IIRC, today is signaled basd on vma properties and in all cases
fast-gup is denied.

Yeah, I forgot that 7af75561e171 eliminated any possibility of
longterm-gup-fast for device-dax, let's not disturb that status quo.

I am slightly confused by this comment -- the status quo is what we are
questioning here -- And we talked about changing that in the past too
(thread below), that longterm-gup-fast was an oversight that that commit
was only applicable to fsdax. [Maybe this is just my english confusion]

No, you have it correct. However that "regression" has gone unnoticed,
so unless there is data showing that gup-fast on device-dax is
critical for longterm page pinning workflows I'm ok for longterm to
continue to trigger gup-slow.