Re: Volunteer to implement Prefault testcase in intel_gpu_tools

[Daniel Vetter <daniel.vetter@ffwll.ch>]

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