From: Daniel Vetter <daniel@ffwll.ch>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Rik van Riel <riel@redhat.com>,
intel-gfx@lists.freedesktop.org,
Dave Chinner <dchinner@redhat.com>,
Hugh Dickins <hughd@google.com>, Michal Hocko <mhocko@suse.cz>,
linux-mm@kvack.org, Mel Gorman <mgorman@suse.de>,
Johannes Weiner <hannes@cmpxchg.org>,
David Rientjes <rientjes@google.com>,
Glauber Costa <glommer@openvz.org>
Subject: Re: [PATCH] mm: Throttle shrinkers harder
Date: Tue, 22 Apr 2014 21:30:41 +0200 [thread overview]
Message-ID: <20140422193041.GD10722@phenom.ffwll.local> (raw)
In-Reply-To: <20140418121416.c022eca055da1b6d81b2cf1b@linux-foundation.org>
On Fri, Apr 18, 2014 at 12:14:16PM -0700, Andrew Morton wrote:
> On Thu, 10 Apr 2014 08:05:06 +0100 Chris Wilson <chris@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.
For more head spinning look at the lock stealing dance we do in our
shrinker callbacks i915_gem_inactive_scan|count(). It's not pretty at all,
but it helps to avoids the dreaded oom in a few more cases. Some review of
our mess of ducttape from -mm developers with actual clue would be really
appreciated ...
-Daniel
> Mel, Johannes: could you take a look please?
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>,
linux-mm@kvack.org, intel-gfx@lists.freedesktop.org,
Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@suse.cz>,
Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Dave Chinner <dchinner@redhat.com>,
Glauber Costa <glommer@openvz.org>,
Hugh Dickins <hughd@google.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH] mm: Throttle shrinkers harder
Date: Tue, 22 Apr 2014 21:30:41 +0200 [thread overview]
Message-ID: <20140422193041.GD10722@phenom.ffwll.local> (raw)
In-Reply-To: <20140418121416.c022eca055da1b6d81b2cf1b@linux-foundation.org>
On Fri, Apr 18, 2014 at 12:14:16PM -0700, Andrew Morton wrote:
> On Thu, 10 Apr 2014 08:05:06 +0100 Chris Wilson <chris@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.
For more head spinning look at the lock stealing dance we do in our
shrinker callbacks i915_gem_inactive_scan|count(). It's not pretty at all,
but it helps to avoids the dreaded oom in a few more cases. Some review of
our mess of ducttape from -mm developers with actual clue would be really
appreciated ...
-Daniel
> Mel, Johannes: could you take a look please?
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-04-22 19:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 7:05 [PATCH] mm: Throttle shrinkers harder Chris Wilson
2014-04-18 19:14 ` Andrew Morton
2014-04-22 19:30 ` Daniel Vetter [this message]
2014-04-22 19:30 ` Daniel Vetter
2014-04-23 21:14 ` Dave Hansen
2014-04-24 5:58 ` Chris Wilson
2014-04-24 5:58 ` Chris Wilson
2014-04-24 15:21 ` Dave Hansen
2014-04-24 15:39 ` Chris Wilson
2014-04-24 15:39 ` Chris Wilson
2014-04-24 22:35 ` Dave Hansen
2014-04-24 22:35 ` Dave Hansen
2014-04-25 7:23 ` Chris Wilson
2014-04-25 7:23 ` Chris Wilson
2014-04-25 17:18 ` Dave Hansen
2014-04-25 17:56 ` Dave Hansen
2014-04-26 13:10 ` Chris Wilson
2014-04-26 13:10 ` Chris Wilson
2014-04-28 16:38 ` Dave Hansen
2014-04-28 16:38 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140422193041.GD10722@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=akpm@linux-foundation.org \
--cc=dchinner@redhat.com \
--cc=glommer@openvz.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.