public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/2] drm/i915: Use remap_pfn_range() to prefault all PTE in a single pass
Date: Thu, 12 Jun 2014 09:15:22 +0200	[thread overview]
Message-ID: <20140612071522.GP5821@phenom.ffwll.local> (raw)
In-Reply-To: <20140611211721.GB25454@bdvolkin-ubuntu-desktop>

On Wed, Jun 11, 2014 at 02:17:21PM -0700, Volkin, Bradley D wrote:
> On Tue, Jun 10, 2014 at 04:14:41AM -0700, Chris Wilson wrote:
> > On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences,
> > Upload rate for 2 linear surfaces:  8134MiB/s -> 8154MiB/s
> > Upload rate for 2 tiled surfaces:   8625MiB/s -> 8632MiB/s
> > Upload rate for 4 linear surfaces:  8127MiB/s -> 8134MiB/s
> > Upload rate for 4 tiled surfaces:   8602MiB/s -> 8629MiB/s
> > Upload rate for 8 linear surfaces:  8124MiB/s -> 8137MiB/s
> > Upload rate for 8 tiled surfaces:   8603MiB/s -> 8624MiB/s
> > Upload rate for 16 linear surfaces: 8123MiB/s -> 8128MiB/s
> > Upload rate for 16 tiled surfaces:  8606MiB/s -> 8618MiB/s
> > Upload rate for 32 linear surfaces: 8121MiB/s -> 8128MiB/s
> > Upload rate for 32 tiled surfaces:  8605MiB/s -> 8614MiB/s
> > Upload rate for 64 linear surfaces: 8121MiB/s -> 8127MiB/s
> > Upload rate for 64 tiled surfaces:  3017MiB/s -> 5127MiB/s
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> The translation from vm_insert_pfn to remap_pfn_range looks correct. I don't know
> these APIs particularly well though. I wonder if there's any reason it would be
> unsafe to call remap_pfn_range from .fault() since it seems to only be used in
> .mmap() handlers in other places. Reading their implementations, nothing jumped
> out, so I'll say

Most drivers just statically relocate their BAR to userspace, we manage it
dynamically. Iirc vm_insert_pfn was more-or-less added for us, too. In any
case I think we're safe.
> 
> Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
> 
> with the note that you may want to take a look just in case.

Thanks for the review, also added the Testcase: tag now that Chris pushed
his igt patch.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 28 +++++++++++++---------------
> >  1 file changed, 13 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index e1f68f06c2ef..7128d389a6ff 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1709,21 +1709,19 @@ int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> >  	pfn >>= PAGE_SHIFT;
> >  
> >  	if (!obj->fault_mappable) {
> > -		int i;
> > -
> > -		for (i = 0; i < obj->base.size >> PAGE_SHIFT; i++) {
> > -			ret = vm_insert_pfn(vma,
> > -					    (unsigned long)vma->vm_start + i * PAGE_SIZE,
> > -					    pfn + i);
> > -			if (ret)
> > -				break;
> > -		}
> > -
> > -		obj->fault_mappable = true;
> > -	} else
> > -		ret = vm_insert_pfn(vma,
> > -				    (unsigned long)vmf->virtual_address,
> > -				    pfn + page_offset);
> > +		ret = remap_pfn_range(vma,
> > +				      vma->vm_start,
> > +				      pfn,
> > +				      obj->base.size,
> > +				      vma->vm_page_prot);
> > +		obj->fault_mappable = ret == 0;
> > +	} else {
> > +		ret = remap_pfn_range(vma,
> > +				      (unsigned long)vmf->virtual_address,
> > +				      pfn + page_offset,
> > +				      PAGE_SIZE,
> > +				      vma->vm_page_prot);
> > +	}
> >  unpin:
> >  	i915_gem_object_ggtt_unpin(obj);
> >  unlock:
> > -- 
> > 2.0.0
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2014-06-12  7:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-10 11:14 [PATCH 1/2] drm/i915: Prefault the entire object on first page fault Chris Wilson
2014-06-10 11:14 ` [PATCH 2/2] drm/i915: Use remap_pfn_range() to prefault all PTE in a single pass Chris Wilson
2014-06-11 21:17   ` Volkin, Bradley D
2014-06-12  7:15     ` Daniel Vetter [this message]
2014-06-12  7:20     ` Chris Wilson
2014-06-12 16:15     ` Daniel Vetter
2014-06-11 20:41 ` [PATCH 1/2] drm/i915: Prefault the entire object on first page fault Volkin, Bradley D
2014-06-12  7:21   ` Chris Wilson
  -- strict thread matches above, loose matches on Subject: below --
2014-06-13 16:26 [PATCH 1/2] mm: Report attempts to overwrite PTE from remap_pfn_range() Chris Wilson
2014-06-13 16:26 ` [PATCH 2/2] drm/i915: Use remap_pfn_range() to prefault all PTE in a single pass Chris Wilson

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=20140612071522.GP5821@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=bradley.d.volkin@intel.com \
    --cc=intel-gfx@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