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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
