From: Thomas Hellstrom <thellstrom@vmware.com>
To: "jglisse@redhat.com" <jglisse@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"willy@infradead.org" <willy@infradead.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"jrdr.linux@gmail.com" <jrdr.linux@gmail.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"minchan@kernel.org" <minchan@kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"will.deacon@arm.com" <will.deacon@arm.com>,
Linux-graphics-maintainer <Linux-graphics-maintainer@vmware.com>,
"mhocko@suse.com" <mhocko@suse.com>,
"ying.huang@intel.com" <ying.huang@intel.com>,
"riel@surriel.com" <riel@surriel.com>
Subject: Re: [RFC PATCH RESEND 0/3] mm modifications / helpers for emulated GPU coherent memory
Date: Thu, 21 Mar 2019 19:51:16 +0000 [thread overview]
Message-ID: <428b30355f4df864235428eaa24e207b8ba6c1ea.camel@vmware.com> (raw)
In-Reply-To: <20190321134603.GB2904@redhat.com>
Hi, Jérôme,
Thanks for commenting. I have a couple of questions / clarifications
below.
On Thu, 2019-03-21 at 09:46 -0400, Jerome Glisse wrote:
> On Thu, Mar 21, 2019 at 01:22:22PM +0000, Thomas Hellstrom wrote:
> > Resending since last series was sent through a mis-configured SMTP
> > server.
> >
> > Hi,
> > This is an early RFC to make sure I don't go too far in the wrong
> > direction.
> >
> > Non-coherent GPUs that can't directly see contents in CPU-visible
> > memory,
> > like VMWare's SVGA device, run into trouble when trying to
> > implement
> > coherent memory requirements of modern graphics APIs. Examples are
> > Vulkan and OpenGL 4.4's ARB_buffer_storage.
> >
> > To remedy, we need to emulate coherent memory. Typically when it's
> > detected
> > that a buffer object is about to be accessed by the GPU, we need to
> > gather the ranges that have been dirtied by the CPU since the last
> > operation,
> > apply an operation to make the content visible to the GPU and clear
> > the
> > the dirty tracking.
> >
> > Depending on the size of the buffer object and the access pattern
> > there are
> > two major possibilities:
> >
> > 1) Use page_mkwrite() and pfn_mkwrite(). (GPU buffer objects are
> > backed
> > either by PCI device memory or by driver-alloced pages).
> > The dirty-tracking needs to be reset by write-protecting the
> > affected ptes
> > and flush tlb. This has a complexity of O(num_dirty_pages), but the
> > write page-fault is of course costly.
> >
> > 2) Use hardware dirty-flags in the ptes. The dirty-tracking needs
> > to be reset
> > by clearing the dirty bits and flush tlb. This has a complexity of
> > O(num_buffer_object_pages) and dirty bits need to be scanned in
> > full before
> > each gpu-access.
> >
> > So in practice the two methods need to be interleaved for best
> > performance.
> >
> > So to facilitate this, I propose two new helpers,
> > apply_as_wrprotect() and
> > apply_as_clean() ("as" stands for address-space) both inspired by
> > unmap_mapping_range(). Users of these helpers are in the making,
> > but needs
> > some cleaning-up.
>
> To be clear this should _only be use_ for mmap of device file ? If so
> the API should try to enforce that as much as possible for instance
> by
> mandating the file as argument so that the function can check it is
> only use in that case. Also big scary comment to make sure no one
> just
> start using those outside this very limited frame.
Fine with me. Perhaps we could BUG() / WARN() on certain VMA flags
instead of mandating the file as argument. That can make sure we
don't accidently hit pages we shouldn't hit.
>
> > There's also a change to x_mkwrite() to allow dropping the mmap_sem
> > while
> > waiting.
>
> This will most likely conflict with userfaultfd write protection.
Are you referring to the x_mkwrite() usage itself or the mmap_sem
dropping facilitation?
> Maybe
> building your thing on top of that would be better.
>
>
...
>
> I will take a cursory look at the patches.
>
Some more questions / clarifications on those as well.
> Cheers,
> Jérôme
next prev parent reply other threads:[~2019-03-21 19:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-21 13:22 [RFC PATCH RESEND 0/3] mm modifications / helpers for emulated GPU coherent memory Thomas Hellstrom
2019-03-21 13:22 ` [RFC PATCH RESEND 1/3] mm: Allow the [page|pfn]_mkwrite callbacks to drop the mmap_sem Thomas Hellstrom
2019-03-21 13:22 ` [RFC PATCH RESEND 2/3] mm: Add an apply_to_pfn_range interface Thomas Hellstrom
2019-03-21 13:52 ` Jerome Glisse
2019-03-21 19:59 ` Thomas Hellstrom
2019-03-21 20:24 ` Jerome Glisse
2019-03-21 13:22 ` [RFC PATCH RESEND 3/3] mm: Add write-protect and clean utilities for address space ranges Thomas Hellstrom
2019-03-21 14:12 ` Jerome Glisse
2019-03-21 20:29 ` Thomas Hellstrom
2019-03-21 21:07 ` Jerome Glisse
2019-03-21 13:46 ` [RFC PATCH RESEND 0/3] mm modifications / helpers for emulated GPU coherent memory Jerome Glisse
2019-03-21 19:51 ` Thomas Hellstrom [this message]
2019-03-21 20:28 ` Jerome Glisse
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=428b30355f4df864235428eaa24e207b8ba6c1ea.camel@vmware.com \
--to=thellstrom@vmware.com \
--cc=Linux-graphics-maintainer@vmware.com \
--cc=akpm@linux-foundation.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jglisse@redhat.com \
--cc=jrdr.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=will.deacon@arm.com \
--cc=willy@infradead.org \
--cc=ying.huang@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).