On Thu, 10 Apr 2014 08:05:06 +0100 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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? _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
