All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: Do not walk all of system memory during show_mem
Date: Mon, 4 Nov 2013 10:08:18 +0000	[thread overview]
Message-ID: <20131104100818.GB2400@suse.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1310161809470.12062@chino.kir.corp.google.com>

On Wed, Oct 16, 2013 at 06:11:56PM -0700, David Rientjes wrote:
> On Wed, 16 Oct 2013, Mel Gorman wrote:
> 
> > It has been reported on very large machines that show_mem is taking almost
> > 5 minutes to display information. This is a serious problem if there is
> > an OOM storm. The bulk of the cost is in show_mem doing a very expensive
> > PFN walk to give us the following information
> > 
> > Total RAM:	Also available as totalram_pages
> > Highmem pages:	Also available as totalhigh_pages
> > Reserved pages:	Can be inferred from the zone structure
> > Shared pages:	PFN walk required
> > Unshared pages:	PFN walk required
> > Quick pages:	Per-cpu walk required
> > 
> > Only the shared/unshared pages requires a full PFN walk but that information
> > is useless. It is also inaccurate as page pins of unshared pages would
> > be accounted for as shared.  Even if the information was accurate, I'm
> > struggling to think how the shared/unshared information could be useful
> > for debugging OOM conditions. Maybe it was useful before rmap existed when
> > reclaiming shared pages was costly but it is less relevant today.
> > 
> > The PFN walk could be optimised a bit but why bother as the information is
> > useless. This patch deletes the PFN walker and infers the total RAM, highmem
> > and reserved pages count from struct zone. It omits the shared/unshared page
> > usage on the grounds that it is useless.  It also corrects the reporting
> > of HighMem as HighMem/MovableOnly as ZONE_MOVABLE has similar problems to
> > HighMem with respect to lowmem/highmem exhaustion.
> > 
> 
> We haven't been hit by this for the oom killer, but we did get hit with 
> this for page allocation failure warnings as a result of having irqs 
> disabled and passing GFP_ATOMIC to the page allocator without GFP_NOWARN.  
> That was the intention of passing SHOW_MEM_FILTER_PAGE_COUNT into 
> show_mem() in 4b59e6c47309 ("mm, show_mem: suppress page counts in 
> non-blockable contexts").
> 
> With this, I assume we can just remove SHOW_MEM_FILTER_PAGE_COUNT 
> entirely?

We could once all the per-arch show_mem functions were updated similar
to lib/show_mem.c. I've added a todo item to do just that. Thanks.


-- 
Mel Gorman
SUSE Labs

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

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: Do not walk all of system memory during show_mem
Date: Mon, 4 Nov 2013 10:08:18 +0000	[thread overview]
Message-ID: <20131104100818.GB2400@suse.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1310161809470.12062@chino.kir.corp.google.com>

On Wed, Oct 16, 2013 at 06:11:56PM -0700, David Rientjes wrote:
> On Wed, 16 Oct 2013, Mel Gorman wrote:
> 
> > It has been reported on very large machines that show_mem is taking almost
> > 5 minutes to display information. This is a serious problem if there is
> > an OOM storm. The bulk of the cost is in show_mem doing a very expensive
> > PFN walk to give us the following information
> > 
> > Total RAM:	Also available as totalram_pages
> > Highmem pages:	Also available as totalhigh_pages
> > Reserved pages:	Can be inferred from the zone structure
> > Shared pages:	PFN walk required
> > Unshared pages:	PFN walk required
> > Quick pages:	Per-cpu walk required
> > 
> > Only the shared/unshared pages requires a full PFN walk but that information
> > is useless. It is also inaccurate as page pins of unshared pages would
> > be accounted for as shared.  Even if the information was accurate, I'm
> > struggling to think how the shared/unshared information could be useful
> > for debugging OOM conditions. Maybe it was useful before rmap existed when
> > reclaiming shared pages was costly but it is less relevant today.
> > 
> > The PFN walk could be optimised a bit but why bother as the information is
> > useless. This patch deletes the PFN walker and infers the total RAM, highmem
> > and reserved pages count from struct zone. It omits the shared/unshared page
> > usage on the grounds that it is useless.  It also corrects the reporting
> > of HighMem as HighMem/MovableOnly as ZONE_MOVABLE has similar problems to
> > HighMem with respect to lowmem/highmem exhaustion.
> > 
> 
> We haven't been hit by this for the oom killer, but we did get hit with 
> this for page allocation failure warnings as a result of having irqs 
> disabled and passing GFP_ATOMIC to the page allocator without GFP_NOWARN.  
> That was the intention of passing SHOW_MEM_FILTER_PAGE_COUNT into 
> show_mem() in 4b59e6c47309 ("mm, show_mem: suppress page counts in 
> non-blockable contexts").
> 
> With this, I assume we can just remove SHOW_MEM_FILTER_PAGE_COUNT 
> entirely?

We could once all the per-arch show_mem functions were updated similar
to lib/show_mem.c. I've added a todo item to do just that. Thanks.


-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2013-11-04 10:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-16 10:42 [PATCH] mm: Do not walk all of system memory during show_mem Mel Gorman
2013-10-16 10:42 ` Mel Gorman
2013-10-17  1:11 ` David Rientjes
2013-10-17  1:11   ` David Rientjes
2013-11-04 10:08   ` Mel Gorman [this message]
2013-11-04 10:08     ` Mel Gorman
2013-12-03 14:57   ` [PATCH] mm, show_mem: Remove SHOW_MEM_FILTER_PAGE_COUNT Mel Gorman
2013-12-03 14:57     ` Mel Gorman
2013-12-03 14:57     ` Mel Gorman
2013-12-03 14:57     ` Mel Gorman
2013-12-03 23:41     ` David Rientjes
2013-12-03 23:41       ` David Rientjes
2013-12-03 23:41       ` David Rientjes
2013-12-03 23:41       ` David Rientjes
2013-10-31  4:55 ` [PATCH] mm: Do not walk all of system memory during show_mem KOSAKI Motohiro
2013-10-31  4:55   ` KOSAKI Motohiro

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=20131104100818.GB2400@suse.de \
    --to=mgorman@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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.