Hi! Adding intel-gfx to keep everyone in the loop. On Tue, Jul 16, 2013 at 10:19 AM, Zhang, Xiong Y <xiong.y.zhang at intel.com> wrote: > This is Xiong from OSV enabling team in OTC BeiJing. > > My manager ask me to solve some intel graphic issues from OSV(ubuntu and > Suse), so recently I am always reading i915 driver, Xorg and Mesa. Now I > have the basic knowledge about intel gfx rendering in Linux. > > I just read gpu memory management in i915 driver and saw your blog on > https://opensource.intel.com/otc-collab/linux-gen-graphics/node/5924. > > One of your mentioned test case is: > > Prefault disabling for the faulting reloc/pwrite/pread tests. Those tests > exercise deadlock conditions with our own pagefault handler, but since we've > added prefault support they're much less effective. Needs a debugfs > interface to disable prefaulting + no-prefault versions of the existing > tests. > > I am interested in writing this test case in intel_gpu_tools to verify my > studying. Could you welcome volunteer to implement this test case ? > > > > > > If you welcome, I have some questions to clarify your requirement: > > 1. Needs a debugfs interface to disable prefaulting + no-prefault > versions of the existing tests. > > In kernel, there are several slow path in reloc/pwrite/pread: > i915_gem_execbuffer_relocate_slow, shmem_pread_slow, shmem_pwrite_slow > > So what?s the function of this debugfs interface ? By prefaulting I mean the calls to fault_in_multipages_writeable and fault_in_multipages_readable in i915_gem.c and i915_gem_execbuffer.c. Those calls prevent with very high chance that we'll hit the slowpaths in shmem and execbuffer code. So we need a module option to disable that code at runtime, like this if(likey(!i915_prefault_disable)) ret = fault_in_multipages_readable(to_user_ptr(args->data_ptr), args->size); else ret = 0; and expose that bool i915_prefault_disable through debugfs. > What?s the difference between disable prefaulting and no-prefault versions. > > 2. Prefault disabling for the faulting reloc/pwrite/pread tests > > In intel_gpu_ tools, gem_exec_faulting_reloc test case can be used to test > i915_gem_execbuffer_relocate_solw, but there is no test case to test > shmem_pread_slow and shmem_pwrite_slow. > > Do you mean you require writing test case to test these two function ? We already have i-g-t testcases which exercise the above interfaces which are capable of hitting the slowpath (without prefaulting). My idea is to add new subtests which first disable prefault through debugfs (I think we can add some drmtest_disable/enable_prefault() helper functions to i-g-t/lib/drmtest.c for that), run the original subtest and then reanable prefaulting again (we need to do that since the piglit test can run subtests in any order). The important tests are imo: - gem_exec_faulting_reloc: this one needs to be converted to the subtest infrastructure first since atm it's just one test. You can take a look at gem_mmap_gtt for how it works. - gem_mmap_gtt: I know the testcase name is a bit misleading, but the subtests test_write and test_read exercise the slowpath in shmem write/read. If you want you could extend the tests in gem_mmap_gtt to also check for functional correctness by writing a special value first in create_pointer (through cpu mmaps so that we still fault on the gtt mmap) and checking that afterwards. If you have that I'd check by placing a printk into the relevant slowpaths in the kernel to make sure your tests actually exercise the right functions. Yours, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
