[Intel-gfx] [PATCH 2/2] drm/i915: Use remap_pfn_range() to prefault all PTE in a single pass
Daniel Vetter
daniel at ffwll.ch
Thu Jun 12 18:15:20 CEST 2014
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 at 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
So apparently wasn't quite the same semantics and remap_pfn_range doesn't
handle concurrent operations too well. Can you please also review Chris'
fixup patch for that?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the Intel-gfx
mailing list