On Fri, Apr 11, 2014 at 10:38:25AM +0200, Daniel Vetter wrote: > On Fri, Apr 11, 2014 at 09:30:20AM +0100, Chris Wilson wrote: > > On Tue, Mar 25, 2014 at 01:23:06PM +0000, Chris Wilson wrote: > > > Try to flush out dirty pages into the swapcache (and from there into the > > > swapfile) when under memory pressure and forced to drop GEM objects from > > > memory. In effect, this should just allow us to discard unused pages for > > > memory reclaim and to start writeback earlier. > > > > > > v2: Hugh Dickins warned that explicitly starting writeback from > > > shrink_slab was prone to deadlocks within shmemfs. > > > > > > Cc: Hugh Dickins <hughd@xxxxxxxxxx> > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > Good news! QA have declared that this series really does prevent the > > random OOM where we have completely unused swap. So all it needs is > > someone brave enough to review. > > Awesome work. > > Do we need the additional patch you've just posted to improve the > writeback stalling after calling shrinkers too, or is that not required? That looks to be required (or at least I hope it provokes the mm gods into doing something sensible) for a different problem. However, that test is still behaving strangely (inactive_anon =~ 2x shmem, it should be almost equal) as it appears that there is severe overallocation, or a leak. But that we can generate massive amounts of writeback from our shrinker which may not be cleared in time for the allocation to succeed is a problem (addressed by that mm patch). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
