[Intel-gfx] [PATCH] mm: Throttle shrinkers harder

[Andrew Morton]

On Thu, 10 Apr 2014 08:05:06 +0100 Chris Wilson <chris at chris-wilson.co.uk> wrote:

> During testing of i915.ko with working texture sets larger than RAM, we
> encounter OOM with plenty of memory still trapped within writeback, e.g:
> 
> [   42.386039] active_anon:10134 inactive_anon:1900781 isolated_anon:32
>  active_file:33 inactive_file:39 isolated_file:0
>  unevictable:0 dirty:0 writeback:337627 unstable:0
>  free:11985 slab_reclaimable:9458 slab_unreclaimable:23614
>  mapped:41 shmem:1560769 pagetables:1276 bounce:0
> 
> If we throttle for writeback following shrink_slab, this gives us time
> to wait upon the writeback generated by the i915.ko shinker:
> 
> [ 4756.750808] active_anon:24386 inactive_anon:900793 isolated_anon:0
>  active_file:23 inactive_file:20 isolated_file:0
>  unevictable:0 dirty:0 writeback:0 unstable:0
>  free:5550 slab_reclaimable:5184 slab_unreclaimable:4888
>  mapped:3 shmem:472393 pagetables:1249 bounce:0
> 
> (Sadly though the test is still failing.)
> 
> Testcase: igt/gem_tiled_swapping
> References: https://bugs.freedesktop.org/show_bug.cgi?id=72742

i915_gem_object_get_pages_gtt() makes my head spin, but
https://bugs.freedesktop.org/attachment.cgi?id=90818 says
"gfp_mask=0x201da" which is 

___GFP_HARDWALL|___GFP_COLD|___GFP_FS|___GFP_IO|___GFP_WAIT|___GFP_MOVABLE|___GFP_HIGHMEM

so this allocation should work and it very bad if the page allocator is
declaring oom while there is so much writeback in flight, assuming the
writeback is to eligible zones.

Mel, Johannes: could you take a look please?