From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: <linux-doc@vger.kernel.org>,
Francois Dugast <francois.dugast@intel.com>,
<linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
Danilo Krummrich <dakr@redhat.com>,
Daniel Vetter <daniel@ffwll.ch>, <intel-xe@lists.freedesktop.org>
Subject: Re: [Intel-xe] [PATCH v5] Documentation/gpu: VM_BIND locking document
Date: Tue, 28 Nov 2023 11:05:18 -0500 [thread overview]
Message-ID: <ZWYPvhDzmqipdhC/@intel.com> (raw)
In-Reply-To: <03712311650b5fcf7162309f13a18dbd240e8a9f.camel@linux.intel.com>
On Tue, Nov 28, 2023 at 04:51:25PM +0100, Thomas Hellström wrote:
> On Mon, 2023-11-27 at 14:36 -0500, Rodrigo Vivi wrote:
> > On Tue, Nov 21, 2023 at 11:40:46AM +0100, Thomas Hellström wrote:
> > > Add the first version of the VM_BIND locking document which is
> > > intended to be part of the xe driver upstreaming agreement.
> > >
> > > The document describes and discuss the locking used during exec-
> > > functions, evicton and for userptr gpu-vmas. Intention is to be
> > > using the
> > > same nomenclature as the drm-vm-bind-async.rst.
> > >
> > > v2:
> > > - s/gvm/gpu_vm/g (Rodrigo Vivi)
> > > - Clarify the userptr seqlock with a pointer to mm/mmu_notifier.c
> > > (Rodrigo Vivi)
> > > - Adjust commit message accordingly.
> > > - Add SPDX license header.
> > >
> > > v3:
> > > - Large update to align with the drm_gpuvm manager locking
> > > - Add "Efficient userptr gpu_vma exec function iteration" section
> > > - Add "Locking at bind- and unbind time" section.
> > >
> > > v4:
> > > - Fix tabs vs space errors by untabifying (Rodrigo Vivi)
> > > - Minor style fixes and typos (Rodrigo Vivi)
> > > - Clarify situations where stale GPU mappings are occurring and how
> > > access through these mappings are blocked. (Rodrigo Vivi)
> > > - Insert into the toctree in implementation_guidelines.rst
> > >
> > > v5:
> > > - Add a section about recoverable page-faults.
> > > - Use local references to other documentation where possible
> > > (Bagas Sanjaya)
> > > - General documentation fixes and typos (Danilo Krummrich and
> > > Boris Brezillon)
> > > - Improve the documentation around locks that need to be grabbed
> > > from the
> > > dm-fence critical section (Boris Brezillon)
> > > - Add more references to the DRM GPUVM helpers (Danilo Krummrich
> > > and
> > > Boriz Brezillon)
> > > - Update the rfc/xe.rst document.
> > >
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> >
> > First of all, with Bagas and Boris latest suggestions, already few
> > free to use:
> >
> > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >
> > But a few minor comments below. Mostly trying to address Boris
> > feeling
> > of long sentences. However, take them with a grain of salt since I'm
> > not
> > a native english speaker. :)
>
> Hi, Rodrigo.
>
> Thanks for the reviewing. I've added most but not all of the
> suggestions in v6. Regarding the comment about "zapping", that's used
> by the core mm for the process of unmapping page-table entries;
> zap_vma_ptes() etc. Merely following that, although I'm not really
> against using unmapping etc.
Perfect then. No concerns from my side.
Thanks,
Rodrigo.
>
> /Thomas
>
prev parent reply other threads:[~2023-11-28 16:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 10:40 [PATCH v5] Documentation/gpu: VM_BIND locking document Thomas Hellström
2023-11-21 13:14 ` Bagas Sanjaya
2023-11-21 13:56 ` Boris Brezillon
2023-11-22 7:49 ` Thomas Hellström
2023-11-27 19:54 ` Danilo Krummrich
2023-11-27 19:36 ` [Intel-xe] " Rodrigo Vivi
2023-11-28 15:51 ` Thomas Hellström
2023-11-28 16:05 ` Rodrigo Vivi [this message]
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=ZWYPvhDzmqipdhC/@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=boris.brezillon@collabora.com \
--cc=dakr@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=francois.dugast@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).