[Intel-gfx] [PATCH] RFC: drm/i915: annote drop_caches debugfs interface with lockdep

Chris Wilson chris at chris-wilson.co.uk
Fri Mar 10 13:54:40 UTC 2017


On Fri, Mar 10, 2017 at 02:31:22PM +0100, Daniel Vetter wrote:
> The trouble we have is that we can't really test all the shrinker
> recursion stuff exhaustively in BAT because any kind of thrashing
> stress test just takes too long.
> 
> But that leaves a really big gap open, since shrinker recursions are
> one of the most annoying bugs. Now lockdep already has support for
> checking allocation deadlocks:
> 
> - Direct reclaim paths are marked up with
>   lockdep_set_current_reclaim_state() and
>   lockdep_clear_current_reclaim_state().
> 
> - Any allocation paths are marked with lockdep_trace_alloc().
> 
> If we simply mark up our debugfs with the reclaim annotations, any
> code and locks taken in there will automatically complete the picture
> with any allocation paths we already have, as long as we have a simple
> testcase in BAT which throws out a few objects using this interface.
> Not stress test or thrashing needed at all.
> 
> Just a quick hack as an RFC after a short discussion with Chris on
> irc.

It matches kswap/shrink_all_memory, looks like the right thing to do.
Considering that we call drop_caches everytime we query memory in igt,
this will then mark the struct_mutex as involved in reclaim long before
we hit kswapd (which is only accidental in current BAT). So, yes a
definite

Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>

as it solves half the problem of writing gem_exec_shrink/basic.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list