linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@gentwo.org>
To: Tejun Heo <tj@kernel.org>
Cc: Jiang Liu <jiang.liu@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@suse.de>,
	David Rientjes <rientjes@google.com>,
	Mike Galbraith <umgwanakikbuti@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Vladimir Davydov <vdavydov@parallels.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Rik van Riel <riel@redhat.com>,
	Wanpeng Li <liwanp@linux.vnet.ibm.com>,
	Zhang Yanfei <zhangyanfei@cn.fujitsu.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Jianyu Zhan <nasa4836@gmail.com>, malc <av1474@comtv.ru>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Fabian Frederick <fabf@skynet.be>,
	Tony Luck <tony.luck@intel.com>,
	linux-mm@kvack.org, linux-hotplug@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
Date: Fri, 11 Jul 2014 12:29:30 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.11.1407111220410.4511@gentwo.org> (raw)
In-Reply-To: <20140711162451.GD30865@htj.dyndns.org>

On Fri, 11 Jul 2014, Tejun Heo wrote:

> On Fri, Jul 11, 2014 at 11:19:14AM -0500, Christoph Lameter wrote:
> > Yes that works. But if we want a consistent node to allocate from (and
> > avoid the fallbacks) then we need this patch. I think this is up to those
> > needing memoryless nodes to figure out what semantics they need.
>
> I'm not following what you're saying.  Are you saying that we need to
> spread numa_mem_id() all over the place for GFP_THISNODE users on
> memless nodes?  There aren't that many users of GFP_THISNODE.

GFP_THISNODE is mostly used by allocators that need memory from specific
nodes. The use of numa_mem_id() there is useful because one will not
get any memory at all when attempting to allocate from a memoryless
node using GFP_THISNODE.

I meant that the relying on fallback to the neighboring nodes without
GFP_THISNODE using numa_node_id() is one approach that may prevent memory
allocators from caching objects for that node because every allocation may
choose a different neighboring node. And the other is the use of
numa_mem_id() which will always use a specific node and avoid fallback to
different node.

The choice is up to those having an interest in memoryless nodes. Which
again I find a pretty strange thing to have that has already proven itself
difficult to maintain in the kernel given the the notion of memory
nodes that should have memory but surprisingly have none. Then there are
the esoteric fallback conditions and special cases introduced. Its a mess.

The best solution may be to just get rid of the whole thing and require
all processors to have a node with memory that is local to them. Current
"memoryless" hardware can simply decide on bootup to pick a memory node
that is local and thus we do not have to deal with it in the core.

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

  reply	other threads:[~2014-07-11 17:29 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-11  7:37 [RFC Patch V1 00/30] Enable memoryless node on x86 platforms Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 01/30] mm, kernel: Use cpu_to_mem()/numa_mem_id() to support memoryless node Jiang Liu
2014-07-11 15:14   ` Paul E. McKenney
2014-07-21 17:15     ` Nishanth Aravamudan
2014-07-21 17:33       ` Paul E. McKenney
2014-07-12 12:32   ` Jens Axboe
2014-07-11  7:37 ` [RFC Patch V1 02/30] mm, sched: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 03/30] mm, net: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 04/30] mm, netfilter: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 05/30] mm, perf: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 06/30] mm, tracing: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 07/30] mm: " Jiang Liu
2014-07-11 13:51   ` Christoph Lameter
2014-07-11 14:42   ` Tejun Heo
2014-07-11 15:13     ` Christoph Lameter
2014-07-11 15:21       ` Tejun Heo
2014-07-11 15:33         ` Tejun Heo
2014-07-11 15:55           ` Christoph Lameter
2014-07-11 15:58             ` Tejun Heo
2014-07-11 16:04               ` Christoph Lameter
2014-07-11 15:58         ` Christoph Lameter
2014-07-11 16:01           ` Tejun Heo
2014-07-11 16:19             ` Christoph Lameter
2014-07-11 16:24               ` Tejun Heo
2014-07-11 17:29                 ` Christoph Lameter [this message]
2014-07-11 18:28                   ` Tejun Heo
2014-07-11 19:11                     ` Christoph Lameter
2014-07-23  3:16                       ` Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 08/30] mm, thp: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 09/30] mm, memcg: " Jiang Liu
2014-07-18  7:36   ` Michal Hocko
2014-07-23  3:18     ` Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 10/30] mm, xfrm: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 11/30] mm, char/mspec.c: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 12/30] mm, IB/qib: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 13/30] mm, i40e: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 14/30] mm, i40evf: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 15/30] mm, igb: " Jiang Liu
2014-07-21 17:42   ` Nishanth Aravamudan
2014-07-21 19:53     ` Alexander Duyck
2014-07-21 21:09       ` Nishanth Aravamudan
2014-07-23  3:20         ` Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 16/30] mm, ixgbe: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 17/30] mm, intel_powerclamp: " Jiang Liu
2014-07-21 17:38   ` Nishanth Aravamudan
2014-07-11  7:37 ` [RFC Patch V1 18/30] mm, bnx2fc: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 19/30] mm, bnx2i: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 20/30] mm, fcoe: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 21/30] mm, irqchip: " Jiang Liu
2014-07-18 12:40   ` Jason Cooper
2014-07-23  3:47     ` Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 22/30] mm, of: " Jiang Liu
2014-07-21 17:52   ` Nishanth Aravamudan
2014-07-28 13:30     ` Grant Likely
2014-07-28 19:26       ` Nishanth Aravamudan
2014-07-11  7:37 ` [RFC Patch V1 23/30] mm, x86: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 24/30] mm, x86/platform/uv: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 25/30] mm, x86, kvm: " Jiang Liu
2014-07-11  7:44   ` Paolo Bonzini
2014-07-11  7:37 ` [RFC Patch V1 26/30] mm, x86, perf: " Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 27/30] x86, numa: Kill useless code to improve code readability Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 28/30] mm: Update _mem_id_[] for every possible CPU when memory configuration changes Jiang Liu
2014-07-21 17:47   ` Nishanth Aravamudan
2014-07-23  8:16     ` Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 29/30] mm, x86: Enable memoryless node support to better support CPU/memory hotplug Jiang Liu
2014-07-24 23:26   ` Nishanth Aravamudan
2014-07-25  1:41     ` Jiang Liu
2014-07-11  7:37 ` [RFC Patch V1 30/30] x86, NUMA: Online node earlier when doing CPU hot-addition Jiang Liu
2014-07-24 23:30   ` Nishanth Aravamudan
2014-07-25  1:43     ` Jiang Liu
2014-07-25  1:44     ` Jiang Liu
2014-07-11  8:29 ` [RFC Patch V1 00/30] Enable memoryless node on x86 platforms Peter Zijlstra
2014-07-11 15:33   ` Greg KH
2014-07-11 20:02     ` Dave Hansen
2014-07-11 20:20     ` Andi Kleen
2014-07-11 20:51       ` Peter Zijlstra
2014-07-11 21:58         ` Andi Kleen
2014-07-15  1:18         ` David Rientjes
2014-07-11 23:51       ` H. Peter Anvin
2014-07-11 22:40     ` Jiri Kosina
2014-07-15  1:19       ` David Rientjes
2014-07-18 17:48         ` Nish Aravamudan
2014-07-21 17:23 ` Nishanth Aravamudan
2014-07-21 17:41   ` Tony Luck
2014-07-21 17:57     ` Nishanth Aravamudan
2014-07-23  8:20       ` Jiang Liu
2014-07-24 23:32         ` Nishanth Aravamudan
2014-07-25  1:50           ` Jiang Liu
2014-08-18 23:30             ` Nishanth Aravamudan
2014-07-21 20:06     ` Peter Zijlstra

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=alpine.DEB.2.11.1407111220410.4511@gentwo.org \
    --to=cl@gentwo.org \
    --cc=akpm@linux-foundation.org \
    --cc=av1474@comtv.ru \
    --cc=catalin.marinas@arm.com \
    --cc=fabf@skynet.be \
    --cc=hannes@cmpxchg.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jiang.liu@linux.intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-hotplug@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liwanp@linux.vnet.ibm.com \
    --cc=mgorman@suse.de \
    --cc=nasa4836@gmail.com \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=tj@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=umgwanakikbuti@gmail.com \
    --cc=vdavydov@parallels.com \
    --cc=zhangyanfei@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox