All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: torvalds@linux-foundation.org, kosaki.motohiro@jp.fujitsu.com,
	lee.schermerhorn@hp.com, peterz@infradead.org, riel@redhat.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	npiggin@suse.de, cl@linux-foundation.org
Subject: Re: [RFC][PATCH] vmscan: don't export nr_saved_scan in /proc/zoneinfo
Date: Mon, 4 May 2009 14:49:15 -0700	[thread overview]
Message-ID: <20090504144915.8d0716d7.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090502024719.GA29730@localhost>

On Sat, 2 May 2009 10:47:19 +0800
Wu Fengguang <fengguang.wu@intel.com> wrote:

> The lru->nr_saved_scan's are not meaningful counters for even kernel
> developers.  They typically are smaller than 32 and are always 0 for
> large lists. So remove them from /proc/zoneinfo.
> 
> Hopefully this interface change won't break too many scripts.
> /proc/zoneinfo is too unstructured to be script friendly, and I wonder
> the affected scripts - if there are any - are still bleeding since the
> not long ago commit "vmscan: split LRU lists into anon & file sets",
> which also touched the "scanned" line :)
> 
> If we are to re-export accumulated vmscan counts in the future, they
> can go to new lines in /proc/zoneinfo instead of the current form, or
> to /sys/devices/system/node/node0/meminfo?
> 

/proc/zoneinfo is unsalvageable :( Shifting future work over to
/sys/devices/system/node/nodeN/meminfo and deprecating /proc/zoneinfo
sounds good to me.


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: torvalds@linux-foundation.org, kosaki.motohiro@jp.fujitsu.com,
	lee.schermerhorn@hp.com, peterz@infradead.org, riel@redhat.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	npiggin@suse.de, cl@linux-foundation.org
Subject: Re: [RFC][PATCH] vmscan: don't export nr_saved_scan in /proc/zoneinfo
Date: Mon, 4 May 2009 14:49:15 -0700	[thread overview]
Message-ID: <20090504144915.8d0716d7.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090502024719.GA29730@localhost>

On Sat, 2 May 2009 10:47:19 +0800
Wu Fengguang <fengguang.wu@intel.com> wrote:

> The lru->nr_saved_scan's are not meaningful counters for even kernel
> developers.  They typically are smaller than 32 and are always 0 for
> large lists. So remove them from /proc/zoneinfo.
> 
> Hopefully this interface change won't break too many scripts.
> /proc/zoneinfo is too unstructured to be script friendly, and I wonder
> the affected scripts - if there are any - are still bleeding since the
> not long ago commit "vmscan: split LRU lists into anon & file sets",
> which also touched the "scanned" line :)
> 
> If we are to re-export accumulated vmscan counts in the future, they
> can go to new lines in /proc/zoneinfo instead of the current form, or
> to /sys/devices/system/node/node0/meminfo?
> 

/proc/zoneinfo is unsalvageable :( Shifting future work over to
/sys/devices/system/node/nodeN/meminfo and deprecating /proc/zoneinfo
sounds good to me.

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

  parent reply	other threads:[~2009-05-04 21:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200904302208.n3UM8t9R016687@imap1.linux-foundation.org>
2009-05-01  1:22 ` [patch 20/22] vmscan: avoid multiplication overflow in shrink_zone() Wu Fengguang
2009-05-01  1:22   ` Wu Fengguang
2009-05-01  2:49   ` Andrew Morton
2009-05-01  2:49     ` Andrew Morton
2009-05-01  6:29     ` Wu Fengguang
2009-05-01  6:29       ` Wu Fengguang
2009-05-02  2:31     ` [PATCH] vmscan: cleanup the scan batching code Wu Fengguang
2009-05-02  2:31       ` Wu Fengguang
2009-05-02  2:47       ` [RFC][PATCH] vmscan: don't export nr_saved_scan in /proc/zoneinfo Wu Fengguang
2009-05-02  2:47         ` Wu Fengguang
2009-05-02 14:21         ` Rik van Riel
2009-05-02 14:21           ` Rik van Riel
2009-05-04 13:50         ` Christoph Lameter
2009-05-04 13:50           ` Christoph Lameter
2009-05-04 14:40         ` KOSAKI Motohiro
2009-05-04 14:40           ` KOSAKI Motohiro
2009-05-04 21:49         ` Andrew Morton [this message]
2009-05-04 21:49           ` Andrew Morton
2009-05-05  7:38           ` Peter Zijlstra
2009-05-05  7:38             ` Peter Zijlstra
2009-05-05 15:43             ` Christoph Lameter
2009-05-05 15:43               ` Christoph Lameter
2009-05-02 14:14       ` [PATCH] vmscan: cleanup the scan batching code Rik van Riel
2009-05-02 14:14         ` Rik van Riel
2009-05-04  8:26       ` Peter Zijlstra
2009-05-04  8:26         ` Peter Zijlstra
2009-05-04 14:41       ` KOSAKI Motohiro
2009-05-04 14:41         ` 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=20090504144915.8d0716d7.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=fengguang.wu@intel.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=lee.schermerhorn@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=torvalds@linux-foundation.org \
    /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.