[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6616185.Wbe1NtApLk@nvdebian>
Date: Thu, 18 Feb 2021 10:00:54 +1100
From: Alistair Popple <apopple@...dia.com>
To: <linux-mm@...ck.org>
CC: Christoph Hellwig <hch@...radead.org>,
Jason Gunthorpe <jgg@...pe.ca>,
John Hubbard <jhubbard@...dia.com>,
Daniel Vetter <daniel@...ll.ch>,
"Nouveau Dev" <nouveau@...ts.freedesktop.org>,
Ben Skeggs <bskeggs@...hat.com>,
"Andrew Morton" <akpm@...ux-foundation.org>,
Linux Doc Mailing List <linux-doc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
<kvm-ppc@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Ralph Campbell <rcampbell@...dia.com>,
Jerome Glisse <jglisse@...hat.com>
Subject: Re: [PATCH 0/9] Add support for SVM atomics in Nouveau
On Thursday, 11 February 2021 6:55:10 PM AEDT Christoph Hellwig wrote:
> On Wed, Feb 10, 2021 at 01:59:13PM -0400, Jason Gunthorpe wrote:
> > Really what you want to do here is leave the CPU page in the VMA and
> > the page tables where it started and deny CPU access to the page. Then
> > all the proper machinery will continue to work.
> >
> > IMHO "migration" is the wrong idea if the data isn't actually moving.
>
> Agreed.
I chose "migration" because device private pages seemed like a good way of
reusing existing code to do what was required (a callback on CPU access).
However I have been reworking this to use mmu notifiers as the callback and it
seems to simplify some things nicely so think I also agree. It removes the
requirement for the pin as well which is nice, I'll post it as a v2 soon.
- Alistair
Powered by blists - more mailing lists