All of lore.kernel.org
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Mel Gorman <mgorman@suse.de>, Andrew Morton <akpm@linux-foundation.org>
Cc: kosaki.motohiro@gmail.com, 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: Thu, 31 Oct 2013 00:55:40 -0400	[thread overview]
Message-ID: <5271E2CC.8040702@gmail.com> (raw)
In-Reply-To: <20131016104228.GM11028@suse.de>

(10/16/13 6:42 AM), 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.
>
> Signed-off-by: Mel Gorman <mgorman@suse.de>

That's ok. I haven't used such information on my long oom debugging history.

Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>


--
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: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Mel Gorman <mgorman@suse.de>, Andrew Morton <akpm@linux-foundation.org>
Cc: kosaki.motohiro@gmail.com, 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: Thu, 31 Oct 2013 00:55:40 -0400	[thread overview]
Message-ID: <5271E2CC.8040702@gmail.com> (raw)
In-Reply-To: <20131016104228.GM11028@suse.de>

(10/16/13 6:42 AM), 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.
>
> Signed-off-by: Mel Gorman <mgorman@suse.de>

That's ok. I haven't used such information on my long oom debugging history.

Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>



  parent reply	other threads:[~2013-10-31  4:55 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
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 ` KOSAKI Motohiro [this message]
2013-10-31  4:55   ` [PATCH] mm: Do not walk all of system memory during show_mem 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=5271E2CC.8040702@gmail.com \
    --to=kosaki.motohiro@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    /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.