All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Michal Hocko <mhocko@kernel.org>,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information
Date: Mon, 12 Sep 2016 10:54:17 +0530	[thread overview]
Message-ID: <57D63C01.9090309@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160909133648.GL4844@dhcp22.suse.cz>

On 09/09/2016 07:06 PM, Michal Hocko wrote:
> On Thu 08-09-16 08:16:58, Anshuman Khandual wrote:
>> > Each individual node in the system has a ZONELIST_FALLBACK zonelist
>> > and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback
>> > order of zones during memory allocations. Sometimes it helps to dump
>> > these zonelists to see the priority order of various zones in them.
>> > 
>> > Particularly platforms which support memory hotplug into previously
>> > non existing zones (at boot), this interface helps in visualizing
>> > which all zonelists of the system at what priority level, the new
>> > hot added memory ends up in. POWER is such a platform where all the
>> > memory detected during boot time remains with ZONE_DMA for good but
>> > then hot plug process can actually get new memory into ZONE_MOVABLE.
>> > So having a way to get the snapshot of the zonelists on the system
>> > after memory or node hot[un]plug is desirable. This change adds one
>> > new sysfs interface (/sys/devices/system/memory/system_zone_details)
>> > which will fetch and dump this information.
> I am still not sure I understand why this is helpful and who is the
> consumer for this interface and how it will benefit from the
> information. Dave (who doesn't seem to be on the CC list re-added) had
> another objection that this breaks one-value-per-file rule for sysfs
> files.

It helps in understanding the relative priority of each memory zone of the
system during various allocation scenarios. Its particularly helpful after
hotplug/unplug of additional memory into previously non existing zone on
a node.

> 
> This all smells like a debugging feature to me and so it should go into
> debugfs.

Sure, will make it a debugfs interface.

--
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: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Michal Hocko <mhocko@kernel.org>,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information
Date: Mon, 12 Sep 2016 10:54:17 +0530	[thread overview]
Message-ID: <57D63C01.9090309@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160909133648.GL4844@dhcp22.suse.cz>

On 09/09/2016 07:06 PM, Michal Hocko wrote:
> On Thu 08-09-16 08:16:58, Anshuman Khandual wrote:
>> > Each individual node in the system has a ZONELIST_FALLBACK zonelist
>> > and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback
>> > order of zones during memory allocations. Sometimes it helps to dump
>> > these zonelists to see the priority order of various zones in them.
>> > 
>> > Particularly platforms which support memory hotplug into previously
>> > non existing zones (at boot), this interface helps in visualizing
>> > which all zonelists of the system at what priority level, the new
>> > hot added memory ends up in. POWER is such a platform where all the
>> > memory detected during boot time remains with ZONE_DMA for good but
>> > then hot plug process can actually get new memory into ZONE_MOVABLE.
>> > So having a way to get the snapshot of the zonelists on the system
>> > after memory or node hot[un]plug is desirable. This change adds one
>> > new sysfs interface (/sys/devices/system/memory/system_zone_details)
>> > which will fetch and dump this information.
> I am still not sure I understand why this is helpful and who is the
> consumer for this interface and how it will benefit from the
> information. Dave (who doesn't seem to be on the CC list re-added) had
> another objection that this breaks one-value-per-file rule for sysfs
> files.

It helps in understanding the relative priority of each memory zone of the
system during various allocation scenarios. Its particularly helpful after
hotplug/unplug of additional memory into previously non existing zone on
a node.

> 
> This all smells like a debugging feature to me and so it should go into
> debugfs.

Sure, will make it a debugfs interface.

  reply	other threads:[~2016-09-12  5:24 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-06  5:34 [PATCH V2 1/2] mm: Export definition of 'zone_names' array through mmzone.h Anshuman Khandual
2016-09-06  5:34 ` Anshuman Khandual
2016-09-06  5:34 ` [PATCH V2 2/2] mm: Add sysfs interface to dump each node's zonelist information Anshuman Khandual
2016-09-06  5:34   ` Anshuman Khandual
2016-09-06  6:11   ` kbuild test robot
2016-09-06  6:49     ` Anshuman Khandual
2016-09-06  6:49       ` Anshuman Khandual
2016-09-06  8:31   ` [PATCH V3] " Anshuman Khandual
2016-09-06  8:31     ` Anshuman Khandual
2016-09-06  9:05     ` kbuild test robot
2016-09-07 12:32       ` Anshuman Khandual
2016-09-07 12:32         ` Anshuman Khandual
2016-09-06 20:36     ` Dave Hansen
2016-09-06 20:36       ` Dave Hansen
2016-09-07  3:08       ` Kees Cook
2016-09-07  3:08         ` Kees Cook
2016-09-07  4:00         ` Anshuman Khandual
2016-09-07  4:00           ` Anshuman Khandual
2016-09-08  2:46     ` [PATCH V4] " Anshuman Khandual
2016-09-08  2:46       ` Anshuman Khandual
2016-09-08  7:44       ` kbuild test robot
2016-09-08 20:24       ` Dave Hansen
2016-09-08 20:24         ` Dave Hansen
2016-09-12  5:27         ` Anshuman Khandual
2016-09-12  5:27           ` Anshuman Khandual
2016-09-12 18:13           ` David Rientjes
2016-09-12 18:13             ` David Rientjes
2016-09-17  4:26             ` Anshuman Khandual
2016-09-17  4:26               ` Anshuman Khandual
2016-09-20  0:54               ` David Rientjes
2016-09-20  0:54                 ` David Rientjes
2016-10-13 14:38                 ` Anshuman Khandual
2016-10-13 14:38                   ` Anshuman Khandual
2016-09-09 13:36       ` Michal Hocko
2016-09-09 13:36         ` Michal Hocko
2016-09-12  5:24         ` Anshuman Khandual [this message]
2016-09-12  5:24           ` Anshuman Khandual

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=57D63C01.9090309@linux.vnet.ibm.com \
    --to=khandual@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.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.