On Wed, 10 Oct 2012 12:07:30 +0100, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > If the system is forced to start kswapd to recover pages, the system is > very starved. Fortunately, kswapd is its own process context and can > wait for the mutex.
Note this doesn't survive inspection with lockdep due to dependency upon pfmemalloc_wait in the direct reclaim path - that is, it is possible for __GFP_FS allocations to wait indefinitely upon kswapd (who in turn may be waiting for the dev->struct_mutex held by the direct reclaimer). As we don't have complete control over all allocations made whilst holding the struct_mutex, we can't control the gfp_t to avoid the deadlock. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
