On 10/20/21 18:12, Dan Williams wrote:
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:
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.
To be fair, it's not surprising that nobody noticed -- my general intent was just to special-case less for device-dax. Not many places use pin_user_pages_fast(FOLL_LONGTERM). This is only exposed on those few cases that do try to use it (e.g. RDMA/IB, vDPA), and specifically when the page fault occurs (that requires fallback-ing to gup-slow) at a higher level than the amount you're pinning e.g. pinning in 2M extents on a device-dax of 1G pagesize. Pin size is limited to a 2M extent at a time by the users I mentioned above -- regardless of the total size of the extent you will be pinning (i.e. 512 struct pages pointers fit one page). But even with all this, this [FOLL_LONGTERM on pin-fast] would still go unnoticed because gup-fast on devmap is just as slow as gup :)