On 10/19/21 20:21, Dan Williams wrote:
On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe jgg@ziepe.ca wrote:
On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
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 discussion.
If it helps moving things forward I could split my series further into:
- the compound page introduction (patches 1-7) of my aforementioned series
- vmemmap deduplication for memory gains (patches 9-14)
- 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.
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]
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):
https://lore.kernel.org/linux-mm/6a18179e-65f7-367d-89a9-d5162f10fef0@oracle...
Yes, basically, whatever test we want for 'deny fast gup foll longterm' is fine.
Personally I'd like to see us move toward a set of flag specifying each special behavior and not a collection of types that imply special behaviors.
Eg we have at least:
- Block gup fast on foll_longterm
- Capture the refcount ==1 and use the pgmap free hook (confusingly called page_is_devmap_managed())
- Always use a swap entry
- page->index/mapping are used in the usual file based way?
Probably more things..
Yes, agree with the principle of reducing type-implied special casing.
OK.
Moving from implicit devmap types to pgmap::flags is rather simple fixup. And I suppose (respectivally) PGMAP_NO_PINF_LONGTERM, PGMAP_MANAGED_FREE_PAGE, PGMAP_USE_SWAP_ENTRY, etc, etc.