From: Jason Gunthorpe <jgg@nvidia.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: intel-xe@lists.freedesktop.org,
Matthew Brost <matthew.brost@intel.com>,
Simona Vetter <simona.vetter@ffwll.ch>,
DRI-devel <dri-devel@lists.freedesktop.org>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] mm/hmm, mm/migrate_device: Allow p2p access and p2p migration
Date: Tue, 15 Oct 2024 10:02:21 -0300 [thread overview]
Message-ID: <20241015130221.GK3394334@nvidia.com> (raw)
In-Reply-To: <19fb79c069b812b164abd4f79d38bb12d2f5afa4.camel@linux.intel.com>
On Tue, Oct 15, 2024 at 02:41:24PM +0200, Thomas Hellström wrote:
> > It has nothing to do with kernel P2P, you are just allowing more
> > selective filtering of dev_private_owner. You should focus on that in
> > the naming, not p2p. ie allow_dev_private()
> >
> > P2P is stuff that is dealing with MEMORY_DEVICE_PCI_P2PDMA.
>
> Yes, although the intention was to incorporate also other fast
> interconnects in "P2P", not just "PCIe P2P", but I'll definitely take a
> look at the naming.
It has nothing to do with that, you are just filtering the device
private pages differently than default.
Your end use might be P2P, but at this API level it certainly is not.
> > This is just allowing more instances of the same driver to co-
> > ordinate
> > their device private memory handle, for whatever purpose.
>
> Exactly, or theoretically even cross-driver.
I don't want to see things like drivers changing their pgmap handles
privately somehow. If we are going to make it cross driver then it
needs to be generalized alot more.
> >
> > Otherwise I don't see a particular problem, though we have talked
> > about widening the matching for device_private more broadly using
> > some
> > kind of grouping tag or something like that instead of a callback.
> > You
> > may consider that as an alternative
>
> Yes. Looked at that, but (if I understand you correctly) that would be
> the case mentioned in the commit message where the group would be set
> up statically at dev_pagemap creation time?
Not necessarily statically, but the membership would be stored in the
pagemap and by updated during hotplug/etc
If this is for P2P then the dynamic behavior is pretty limited, some
kind of NxN bitmap.
> > hmm_range struct inside a caller private data struct and use that
> > instead if inventing a whole new struct and pointer.
>
> Our first attempt was based on that but then that wouldn't be reusable
> in the migrate_device.c code. Hence the extra indirection.
It is performance path, you should prefer duplication rather than
slowing it down..
Jason
next prev parent reply other threads:[~2024-10-15 13:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-15 11:13 Thomas Hellström
2024-10-15 11:21 ` Thomas Hellström
2024-10-15 12:17 ` Jason Gunthorpe
2024-10-15 12:41 ` Thomas Hellström
2024-10-15 13:02 ` Jason Gunthorpe [this message]
2024-10-15 13:17 ` Thomas Hellström
2024-10-16 4:46 ` 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=20241015130221.GK3394334@nvidia.com \
--to=jgg@nvidia.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=simona.vetter@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.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