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@xxxxxxxxxxxxxxxxxx> as it solves half the problem of writing gem_exec_shrink/basic. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
