On Wed, Oct 20, 2021 at 10:09 AM Joao Martins joao.m.martins@oracle.com wrote:
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]
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.