[Intel-gfx] [PATCH 3/3] drm/i915: run shmem_pread_fast() after page fault
Chris Wilson
chris at chris-wilson.co.uk
Fri Jul 19 11:19:40 CEST 2013
On Fri, Jul 19, 2013 at 08:52:39AM +0000, Zhang, Xiong Y wrote:
> It just influence one page.
> During my test, I found one read slow path info when enable prefault. So I add this patch.
> Why don't move fault_in_multipages_writeable() from i915_gem_shmem_pread() to the beginning of i915_gem_pread_ioctl() ?
> So the pread_ioctl() is like pwrite_ioctl(). Is the cost of fault_in_multipages_writeable() lager than fault_in_multipages_readable() ?
The essence of the problem with fault_in_multipages_writeable() is that
it writes a 0 without us guarranteeing to replace it with correct data.
Real world usage (at least in the ddx) of pread is limited to UXA
readbacks (x11perf -shmget would be the best test case), and more or
less gen2 readbacks in SNA. (For SNA we first try to use CPU bo and
various maps before resorting to pread.)
You will want to extend the microbenchmarks such as i-g-t/gem_gtt_speed
to cover cases which can be prefaulted and where prefaulting helps. If
you can measure a difference between the paths in the current code, you
are ready to see if you can measure an improvement from your patch.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list