All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	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: Wed, 23 Apr 2014 14:14:36 -0700	[thread overview]
Message-ID: <53582D3C.1010509@intel.com> (raw)
In-Reply-To: <20140422193041.GD10722@phenom.ffwll.local>

On 04/22/2014 12:30 PM, Daniel Vetter 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

Could you get some dumps of the entire set of OOM information?  These
are only tiny snippets.

Also, the vmstat output from the bug:

> https://bugs.freedesktop.org/show_bug.cgi?id=72742

shows there being an *AWFUL* lot of swap I/O going on here.  From the
looks of it, we stuck ~2GB in swap and evicted another 1.5GB of page
cache (although I guess that could be double-counting tmpfs getting
swapped out too).  Hmmm, was this one of the cases where you actually
ran _out_ of swap?

>  2  0  19472  33952    296 3610324    0 19472     0 19472 1474  151  3 27 71  0
>  4  0 484964  66468    296 3175864    0 465492     0 465516 2597 1395  0 32 66  2
>  0  2 751940  23692    980 3022884    0 266976   688 266976 3681  636  0 27 66  6
> procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
>  2  1 1244580 295336    988 2606984    0 492896     0 492908 1237  311  1  9 50 41
>  0  2 2047996  28760    988 2037144    0 803160     0 803160 1221 1291  1 15 69 14


--
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>

  reply	other threads:[~2014-04-23 21:14 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
2014-04-22 19:30     ` Daniel Vetter
2014-04-23 21:14     ` Dave Hansen [this message]
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=53582D3C.1010509@intel.com \
    --to=dave.hansen@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chris-wilson.co.uk \
    --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.