From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: David Rientjes <rientjes@google.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org
Subject: Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information
Date: Thu, 13 Oct 2016 20:08:03 +0530 [thread overview]
Message-ID: <57FF9C4B.5040004@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1609191752080.53329@chino.kir.corp.google.com>
On 09/20/2016 06:24 AM, David Rientjes wrote:
> On Sat, 17 Sep 2016, Anshuman Khandual wrote:
>
>>> > > I'm questioning if this information can be inferred from information
>>> > > already in /proc/zoneinfo and sysfs. We know the no-fallback zonelist is
>>> > > going to include the local node, and we know the other zonelists are
>>> > > either node ordered or zone ordered (or do we need to extend
>>> > > vm.numa_zonelist_order for default?). I may have missed what new
>>> > > knowledge this interface is imparting on us.
>> >
>> > IIUC /proc/zoneinfo lists down zone internal state and statistics for
>> > all zones on the system at any given point of time. The no-fallback
>> > list contains the zones from the local node and fallback (which gets
>> > used more often than the no-fallback) list contains all zones either
>> > in node-ordered or zone-ordered manner. In most of the platforms the
>> > default being the node order but the sequence of present nodes in
>> > that order is determined by various factors like NUMA distance, load,
>> > presence of CPUs on the node etc. This order of nodes in the fallback
>> > list is the most important information derived out of this interface.
>> >
> The point is that all of this can be inferred with information already
> provided, so the additional interface seems unnecessary. The only
> extension I think that is needed is to determine if the order is node or
> zone when vm.numa_zonelist_order == default and we shouldn't parse this
> from dmesg.
Okay. Seems like the general view is that this interface is not necessary.
Hence wont be posting the debugfs version for now.
--
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: David Rientjes <rientjes@google.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org
Subject: Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information
Date: Thu, 13 Oct 2016 20:08:03 +0530 [thread overview]
Message-ID: <57FF9C4B.5040004@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1609191752080.53329@chino.kir.corp.google.com>
On 09/20/2016 06:24 AM, David Rientjes wrote:
> On Sat, 17 Sep 2016, Anshuman Khandual wrote:
>
>>> > > I'm questioning if this information can be inferred from information
>>> > > already in /proc/zoneinfo and sysfs. We know the no-fallback zonelist is
>>> > > going to include the local node, and we know the other zonelists are
>>> > > either node ordered or zone ordered (or do we need to extend
>>> > > vm.numa_zonelist_order for default?). I may have missed what new
>>> > > knowledge this interface is imparting on us.
>> >
>> > IIUC /proc/zoneinfo lists down zone internal state and statistics for
>> > all zones on the system at any given point of time. The no-fallback
>> > list contains the zones from the local node and fallback (which gets
>> > used more often than the no-fallback) list contains all zones either
>> > in node-ordered or zone-ordered manner. In most of the platforms the
>> > default being the node order but the sequence of present nodes in
>> > that order is determined by various factors like NUMA distance, load,
>> > presence of CPUs on the node etc. This order of nodes in the fallback
>> > list is the most important information derived out of this interface.
>> >
> The point is that all of this can be inferred with information already
> provided, so the additional interface seems unnecessary. The only
> extension I think that is needed is to determine if the order is node or
> zone when vm.numa_zonelist_order == default and we shouldn't parse this
> from dmesg.
Okay. Seems like the general view is that this interface is not necessary.
Hence wont be posting the debugfs version for now.
next prev parent reply other threads:[~2016-10-13 14:38 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 [this message]
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
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=57FF9C4B.5040004@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=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.