All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
To: David Rientjes <rientjes@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Fengguang Wu <fengguang.wu@intel.com>,
	David Cohen <david.a.cohen@linux.intel.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Damien Ramonda <damien.ramonda@intel.com>,
	Jan Kara <jack@suse.cz>, linux-mm <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH V5] mm readahead: Fix readahead fail for no local memory and limit readahead pages
Date: Mon, 17 Feb 2014 11:28:03 -0800	[thread overview]
Message-ID: <20140217192803.GA14586@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1402140244330.12099@chino.kir.corp.google.com>

On 14.02.2014 [02:54:06 -0800], David Rientjes wrote:
> On Thu, 13 Feb 2014, Nishanth Aravamudan wrote:
> 
> > There is an open issue on powerpc with memoryless nodes (inasmuch as we
> > can have them, but the kernel doesn't support it properly). There is a
> > separate discussion going on on linuxppc-dev about what is necessary for
> > CONFIG_HAVE_MEMORYLESS_NODES to be supported.
> > 
> 
> Yeah, and this is causing problems with the slub allocator as well.
> 
> > Apologies for hijacking the thread, my comments below were purely about
> > the memoryless node support, not about readahead specifically.
> > 
> 
> Neither you nor Raghavendra have any reason to apologize to anybody.  
> Memoryless node support on powerpc isn't working very well right now and 
> you're trying to fix it, that fix is needed both in this thread and in 
> your fixes for slub.  It's great to see both of you working hard on your 
> platform to make it work the best.
> 
> I think what you'll need to do in addition to your 
> CONFIG_HAVE_MEMORYLESS_NODE fix, which is obviously needed, is to enable 
> CONFIG_USE_PERCPU_NUMA_NODE_ID for the same NUMA configurations and then 
> use set_numa_node() or set_cpu_numa_node() to properly store the mapping 
> between cpu and node rather than numa_cpu_lookup_table.  Then you should 
> be able to do away with your own implementation of cpu_to_node().
> 
> After that, I think it should be as simple as doing
> 
> 	set_numa_node(cpu_to_node(cpu));
> 	set_numa_mem(local_memory_node(cpu_to_node(cpu)));
> 
> probably before taking vector_lock in smp_callin().  The cpu-to-node 
> mapping should be done much earlier in boot while the nodes are being 
> initialized, I don't think there should be any problem there.

vector_lock/smp_callin are ia64 specific things, I believe? I think the
equivalent is just in start_secondary() for powerpc? (which in fact is
what calls smp_callin on powerpc).

Here is what I'm running into now:

setup_arch ->
	do_init_bootmem ->
		cpu_numa_callback ->
			numa_setup_cpu ->
				map_cpu_to_node -> 
					update_numa_cpu_lookup_table

Which current updates the powerpc specific numa_cpu_lookup_table. I
would like to update that function to use set_cpu_numa_node() and
set_cpu_numa_mem(), but local_memory_node() is not yet functional
because build_all_zonelists is called later in start_kernel. Would it
make sense for first_zones_zonelist() to return NUMA_NO_NODE if we
don't have a zone?

Thanks,
Nish

--
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: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
To: David Rientjes <rientjes@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Fengguang Wu <fengguang.wu@intel.com>,
	David Cohen <david.a.cohen@linux.intel.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Damien Ramonda <damien.ramonda@intel.com>,
	Jan Kara <jack@suse.cz>, linux-mm <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH V5] mm readahead: Fix readahead fail for no local memory and limit readahead pages
Date: Mon, 17 Feb 2014 11:28:03 -0800	[thread overview]
Message-ID: <20140217192803.GA14586@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1402140244330.12099@chino.kir.corp.google.com>

On 14.02.2014 [02:54:06 -0800], David Rientjes wrote:
> On Thu, 13 Feb 2014, Nishanth Aravamudan wrote:
> 
> > There is an open issue on powerpc with memoryless nodes (inasmuch as we
> > can have them, but the kernel doesn't support it properly). There is a
> > separate discussion going on on linuxppc-dev about what is necessary for
> > CONFIG_HAVE_MEMORYLESS_NODES to be supported.
> > 
> 
> Yeah, and this is causing problems with the slub allocator as well.
> 
> > Apologies for hijacking the thread, my comments below were purely about
> > the memoryless node support, not about readahead specifically.
> > 
> 
> Neither you nor Raghavendra have any reason to apologize to anybody.  
> Memoryless node support on powerpc isn't working very well right now and 
> you're trying to fix it, that fix is needed both in this thread and in 
> your fixes for slub.  It's great to see both of you working hard on your 
> platform to make it work the best.
> 
> I think what you'll need to do in addition to your 
> CONFIG_HAVE_MEMORYLESS_NODE fix, which is obviously needed, is to enable 
> CONFIG_USE_PERCPU_NUMA_NODE_ID for the same NUMA configurations and then 
> use set_numa_node() or set_cpu_numa_node() to properly store the mapping 
> between cpu and node rather than numa_cpu_lookup_table.  Then you should 
> be able to do away with your own implementation of cpu_to_node().
> 
> After that, I think it should be as simple as doing
> 
> 	set_numa_node(cpu_to_node(cpu));
> 	set_numa_mem(local_memory_node(cpu_to_node(cpu)));
> 
> probably before taking vector_lock in smp_callin().  The cpu-to-node 
> mapping should be done much earlier in boot while the nodes are being 
> initialized, I don't think there should be any problem there.

vector_lock/smp_callin are ia64 specific things, I believe? I think the
equivalent is just in start_secondary() for powerpc? (which in fact is
what calls smp_callin on powerpc).

Here is what I'm running into now:

setup_arch ->
	do_init_bootmem ->
		cpu_numa_callback ->
			numa_setup_cpu ->
				map_cpu_to_node -> 
					update_numa_cpu_lookup_table

Which current updates the powerpc specific numa_cpu_lookup_table. I
would like to update that function to use set_cpu_numa_node() and
set_cpu_numa_mem(), but local_memory_node() is not yet functional
because build_all_zonelists is called later in start_kernel. Would it
make sense for first_zones_zonelist() to return NUMA_NO_NODE if we
don't have a zone?

Thanks,
Nish


  reply	other threads:[~2014-02-17 19:28 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-22 10:53 [RFC PATCH V5] mm readahead: Fix readahead fail for no local memory and limit readahead pages Raghavendra K T
2014-01-22 10:53 ` Raghavendra K T
2014-02-03  8:30 ` Raghavendra K T
2014-02-03  8:30   ` Raghavendra K T
2014-02-06 22:51 ` Andrew Morton
2014-02-06 22:51   ` Andrew Morton
2014-02-06 22:58   ` David Rientjes
2014-02-06 22:58     ` David Rientjes
2014-02-06 23:22     ` Andrew Morton
2014-02-06 23:22       ` Andrew Morton
2014-02-06 23:48       ` David Rientjes
2014-02-06 23:48         ` David Rientjes
2014-02-06 23:58         ` David Rientjes
2014-02-06 23:58           ` David Rientjes
2014-02-07 10:42           ` Raghavendra K T
2014-02-07 10:42             ` Raghavendra K T
2014-02-07 20:41             ` David Rientjes
2014-02-07 20:41               ` David Rientjes
2014-02-10  8:21               ` Raghavendra K T
2014-02-10  8:21                 ` Raghavendra K T
2014-02-10 10:05                 ` David Rientjes
2014-02-10 10:05                   ` David Rientjes
2014-02-10 12:25                   ` Raghavendra K T
2014-02-10 12:25                     ` Raghavendra K T
2014-02-10 21:35                     ` David Rientjes
2014-02-10 21:35                       ` David Rientjes
2014-02-13  7:07                       ` Raghavendra K T
2014-02-13  7:07                         ` Raghavendra K T
2014-02-13  8:05                         ` David Rientjes
2014-02-13  8:05                           ` David Rientjes
2014-02-13 10:04                           ` Raghavendra K T
2014-02-13 10:04                             ` Raghavendra K T
2014-02-13 22:41                             ` David Rientjes
2014-02-13 22:41                               ` David Rientjes
2014-02-14  0:14                               ` Nishanth Aravamudan
2014-02-14  0:14                                 ` Nishanth Aravamudan
2014-02-14  0:37                                 ` Linus Torvalds
2014-02-14  0:37                                   ` Linus Torvalds
2014-02-14  0:45                                   ` Andrew Morton
2014-02-14  0:45                                     ` Andrew Morton
2014-02-14  4:32                                   ` Nishanth Aravamudan
2014-02-14  4:32                                     ` Nishanth Aravamudan
2014-02-14 10:54                                     ` David Rientjes
2014-02-14 10:54                                       ` David Rientjes
2014-02-17 19:28                                       ` Nishanth Aravamudan [this message]
2014-02-17 19:28                                         ` Nishanth Aravamudan
2014-02-17 23:14                                         ` David Rientjes
2014-02-17 23:14                                           ` David Rientjes
2014-02-18  1:31                                           ` Nishanth Aravamudan
2014-02-18  1:31                                             ` Nishanth Aravamudan
2014-02-17 22:59                                     ` Linus Torvalds
2014-02-17 22:59                                       ` Linus Torvalds
2014-02-14  7:43                                   ` Jan Kara
2014-02-14  7:43                                     ` Jan Kara
2014-02-17 22:57                                     ` Linus Torvalds
2014-02-17 22:57                                       ` Linus Torvalds
2014-02-14  5:47                               ` Nishanth Aravamudan
2014-02-14  5:47                                 ` Nishanth Aravamudan
2014-02-13 21:06                           ` Andrew Morton
2014-02-13 21:06                             ` Andrew Morton
2014-02-13 21:42                             ` Nishanth Aravamudan
2014-02-13 21:42                               ` Nishanth Aravamudan
2014-02-10  8:29   ` [RFC PATCH V5 RESEND] " Raghavendra K T
2014-02-10  8:29     ` Raghavendra K T

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=20140217192803.GA14586@linux.vnet.ibm.com \
    --to=nacc@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=damien.ramonda@intel.com \
    --cc=david.a.cohen@linux.intel.com \
    --cc=fengguang.wu@intel.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=raghavendra.kt@linux.vnet.ibm.com \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.