From: Jason Gunthorpe <jgg@ziepe.ca>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Martin Oliveira <Martin.Oliveira@eideticom.com>,
Christoph Hellwig <hch@lst.de>,
Dan Williams <dan.j.williams@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: P2PDMA in Userspace RDMA
Date: Thu, 9 May 2024 14:42:04 -0300 [thread overview]
Message-ID: <20240509174204.GV4718@ziepe.ca> (raw)
In-Reply-To: <fa2d39cf-b0df-4674-979d-b775d5077bce@deltatee.com>
On Thu, May 09, 2024 at 11:31:33AM -0600, Logan Gunthorpe wrote:
> Hi Jason,
>
> We've become interested again in enabling P2PDMA transactions with
> userspace RDMA and the NVMe CMBs we are already exporting to userspace
> from our previous work.
>
> Enabling FOLL_PCI_P2PDMA in ib_umem_get is almost a trivial change, but
> there are two issues holding us back.
>
> The biggest issue is that we disallowed FOLL_LONGTERM with
> FOLL_PCI_P2PDMA out of concern that P2PDMA had the same problem as
> fs-dax.
Yeah, it was not a great outcome of that issue.
> See [1] to review the discussion from 2 years ago. However, in
> trying to understand the problem again, I'm not sure that concern was
> valid. In P2PDMA, unmap_mapping_range() is strictly only called on
> driver unbind when everything is getting torn down[2]. The next thing
> that happens immediately after the unmap is the tear down of the pgmap
> which drops the elevated reference on the pages and waits for all page's
> reference counts to go back to zero. This will effectively wait until
> all longterm pins involving the memory have been released. This can
> cause a hang on unbind but, in your words, its "annoying not critical".
Yes
But you are looking at the code as it is right now, and stuff has been
quitely fixed with the pgmap refcount area since. I think it is
probably good now. IIRC it was pushed over the finish line when the
ZONE_DEVICE/PRIVATE pages were converted to have normal reference
counting.
If p2p is following the new ZONE_DEVICE scheme then it should be fine.
It would be good to read over Alistair's latest series fixing up fsdax
refcounts to see if anything pops out as problematic specifically with
the P2P case.
Otherwise a careful check through is probably all that is needed.
> The other issue we hit when enabling this feature is the check for
> vma_needs_dirty_tracking() in writable_file_mapping_allowed() during the
> gup flow. This hits because the p2pdma code is using the common
> sysfs/kernfs infrastructure to create the VMA which installs a
> page_mkwrite operator()[4] to change the file update time on write.
Ah.
> I don't think this feature really makes any sense for the P2PDMA
> sysfs file which is really operating as an allocator in userspace --
> the time on the file does not really need to reflect the last write
> of some process that wrote to memory allocated using it.
Right, you shouldn't have mkwrite for these pages.
Jason
next prev parent reply other threads:[~2024-05-09 17:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-09 17:31 P2PDMA in Userspace RDMA Logan Gunthorpe
2024-05-09 17:42 ` Jason Gunthorpe [this message]
2024-05-09 20:48 ` Alistair Popple
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240509174204.GV4718@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=Martin.Oliveira@eideticom.com \
--cc=dan.j.williams@intel.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=logang@deltatee.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 read-only IMAP folder(s) and NNTP newsgroup(s).