public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: Simona Vetter <simona.vetter@ffwll.ch>
To: David Hildenbrand <david@redhat.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	John Hubbard <jhubbard@nvidia.com>,
	nouveau@lists.freedesktop.org, Jason Gunthorpe <jgg@nvidia.com>,
	Alistair Popple <apopple@nvidia.com>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Karol Herbst <kherbst@redhat.com>, Lyude Paul <lyude@redhat.com>,
	Danilo Krummrich <dakr@kernel.org>
Subject: Re: [Question] Are "device exclusive non-swap entries" / "SVM atomics in Nouveau" still getting used in practice?
Date: Thu, 23 Jan 2025 16:08:16 +0100	[thread overview]
Message-ID: <Z5JbYC2-slPU0l3n@phenom.ffwll.local> (raw)
In-Reply-To: <346518a4-a090-4eaa-bc04-634388fd4ca3@redhat.com>

On Thu, Jan 23, 2025 at 11:20:37AM +0100, David Hildenbrand wrote:
> Hi,
> 
> I keep finding issues in our implementation of "device exclusive non-swap
> entries", and the way it messes with mapcounts is disgusting.
> 
> As a reminder, what we do here is to replace a PTE pointing to an anonymous
> page by a "device exclusive non-swap entry".
> 
> As long as the original PTE is in place, the only CPU can access it, as soon
> as the "device exclusive non-swap entry" is in place, only the device can
> access it. Conversion back and forth is triggered by CPU / device faults.
> 
> I have fixes/reworks/simplifications for most things, but as there is only a
> "real" single user in-tree of make_device_exclusive():
> 
> 	drivers/gpu/drm/nouveau/nouveau_svm.c
> 
> to "support SVM atomics in Nouveau [1]"
> 
> naturally I am wondering: is this still a thing on actual hardware, or is it
> already stale on recent hardware and not really required anymore?
> 
> 
> [1] https://lore.kernel.org/linux-kernel//6621654.gmDyfcmpjF@nvdebian/T/

As long as you don't have a coherent interconnect it's needed. On intel
discrete device atomics require device memory, so they need full hmm
migration (and hence wont use this function even once we land intel gpu
svm code in upstream). On integrated the gpu is tied into the coherency
fabric, so there it's not needed.

I think the more fundamental question with both this function here and
with forced migration to device memory is that there's no guarantee it
will work out. At least that's my understanding. And for this gpu device
atomics without coherent interconnect idea to work, we'd need to be able
to guarantee that we can make any page device exclusive. So from my side I
have some pretty big question marks on this entire thing overall.

Cheers, Sima
-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


  reply	other threads:[~2025-01-23 15:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-23 10:20 [Question] Are "device exclusive non-swap entries" / "SVM atomics in Nouveau" still getting used in practice? David Hildenbrand
2025-01-23 15:08 ` Simona Vetter [this message]
2025-01-24 10:44   ` David Hildenbrand
2025-01-24 14:11     ` Jason Gunthorpe
2025-01-24 14:39       ` David Hildenbrand
2025-01-24 15:28     ` Simona Vetter
2025-01-24 17:54       ` David Hildenbrand
2025-01-28  0:09         ` Alistair Popple
2025-01-28 20:14           ` Simona Vetter
2025-01-28 20:24             ` David Hildenbrand
2025-01-29 10:48               ` Simona Vetter
2025-01-29 11:28                 ` Simona Vetter
2025-01-29 11:31                   ` David Hildenbrand
2025-01-29 14:05                     ` Simona Vetter
2025-01-29 16:13                       ` David Hildenbrand
2025-01-30  8:55                         ` Simona Vetter

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=Z5JbYC2-slPU0l3n@phenom.ffwll.local \
    --to=simona.vetter@ffwll.ch \
    --cc=apopple@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=david@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=kherbst@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=lyude@redhat.com \
    --cc=nouveau@lists.freedesktop.org \
    /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