[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