On Thu, Feb 06, 2014 at 11:28:12AM -0800, Nishanth Aravamudan wrote:
On 06.02.2014 [10:59:55 -0800], Nishanth Aravamudan wrote:
On 06.02.2014 [17:04:18 +0900], Joonsoo Kim wrote:
On Wed, Feb 05, 2014 at 06:07:57PM -0800, Nishanth Aravamudan wrote:
On 24.01.2014 [16:25:58 -0800], David
On Wed, 5 Feb 2014, Nishanth Aravamudan wrote:
Right so if we are ignoring the node then the simplest thing to do is to
not deactivate the current cpu slab but to take an object from it.
Ok, that's what Anton's patch does, I believe. Are you ok with that
patch as it is?
No. Again his
On 06.02.2014 [10:59:55 -0800], Nishanth Aravamudan wrote:
On 06.02.2014 [17:04:18 +0900], Joonsoo Kim wrote:
On Wed, Feb 05, 2014 at 06:07:57PM -0800, Nishanth Aravamudan wrote:
On 24.01.2014 [16:25:58 -0800], David Rientjes wrote:
On Fri, 24 Jan 2014, Nishanth Aravamudan wrote:
On Tue, 4 Feb 2014, Nishanth Aravamudan wrote:
If the target node allocation fails (for whatever reason) then I would
recommend for simplicities sake to change the target node to
NUMA_NO_NODE and just take whatever is in the current cpu slab. A more
complex solution would be to look
On 24.01.2014 [16:25:58 -0800], David Rientjes wrote:
On Fri, 24 Jan 2014, Nishanth Aravamudan wrote:
Thank you for clarifying and providing a test patch. I ran with this on
the system showing the original problem, configured to have 15GB of
memory.
With your patch after boot:
On 05.02.2014 [13:28:03 -0600], Christoph Lameter wrote:
On Tue, 4 Feb 2014, Nishanth Aravamudan wrote:
If the target node allocation fails (for whatever reason) then I would
recommend for simplicities sake to change the target node to
NUMA_NO_NODE and just take whatever is in the
On Mon, 3 Feb 2014, Nishanth Aravamudan wrote:
Yes, sorry for my lack of clarity. I meant Joonsoo's latest patch for
the $SUBJECT issue.
Hmmm... I am not sure that this is a general solution. The fallback to
other nodes can not only occur because a node has no memory as his patch
assumes.
If
On 04.02.2014 [14:39:32 -0600], Christoph Lameter wrote:
On Mon, 3 Feb 2014, Nishanth Aravamudan wrote:
Yes, sorry for my lack of clarity. I meant Joonsoo's latest patch for
the $SUBJECT issue.
Hmmm... I am not sure that this is a general solution. The fallback to
other nodes can not
On 28.01.2014 [10:29:47 -0800], Nishanth Aravamudan wrote:
On 27.01.2014 [14:58:05 +0900], Joonsoo Kim wrote:
On Fri, Jan 24, 2014 at 05:10:42PM -0800, Nishanth Aravamudan wrote:
On 24.01.2014 [16:25:58 -0800], David Rientjes wrote:
On Fri, 24 Jan 2014, Nishanth Aravamudan wrote:
On Mon, 3 Feb 2014, Nishanth Aravamudan wrote:
So what's the status of this patch? Christoph, do you think this is fine
as it is?
Certainly enabling CONFIG_MEMORYLESS_NODES is the right thing to do and I
already acked the patch.
___
Linuxppc-dev
On 03.02.2014 [21:38:36 -0600], Christoph Lameter wrote:
On Mon, 3 Feb 2014, Nishanth Aravamudan wrote:
So what's the status of this patch? Christoph, do you think this is fine
as it is?
Certainly enabling CONFIG_MEMORYLESS_NODES is the right thing to do and I
already acked the patch.
On Wed, 29 Jan 2014, Nishanth Aravamudan wrote:
exactly what the caller intends.
int searchnode = node;
if (node == NUMA_NO_NODE)
searchnode = numa_mem_id();
if (!node_present_pages(node))
searchnode = local_memory_node(node);
The difference in semantics from the previous is
On Tue, 28 Jan 2014, Nishanth Aravamudan wrote:
This helps about the same as David's patch -- but I found the reason
why! ppc64 doesn't set CONFIG_HAVE_MEMORYLESS_NODES :) Expect a patch
shortly for that and one other case I found.
Oww...
___
On 28.01.2014 [10:29:47 -0800], Nishanth Aravamudan wrote:
On 27.01.2014 [14:58:05 +0900], Joonsoo Kim wrote:
On Fri, Jan 24, 2014 at 05:10:42PM -0800, Nishanth Aravamudan wrote:
On 24.01.2014 [16:25:58 -0800], David Rientjes wrote:
On Fri, 24 Jan 2014, Nishanth Aravamudan wrote:
On 27.01.2014 [14:58:05 +0900], Joonsoo Kim wrote:
On Fri, Jan 24, 2014 at 05:10:42PM -0800, Nishanth Aravamudan wrote:
On 24.01.2014 [16:25:58 -0800], David Rientjes wrote:
On Fri, 24 Jan 2014, Nishanth Aravamudan wrote:
Thank you for clarifying and providing a test patch. I ran
On Fri, 24 Jan 2014, David Rientjes wrote:
kmalloc_node(nid) and kmem_cache_alloc_node(nid) should fallback to nodes
other than nid when memory can't be allocated, these functions only
indicate a preference.
The nid passed indicated a preference unless __GFP_THIS_NODE is specified.
Then the
On Fri, 24 Jan 2014, Nishanth Aravamudan wrote:
As to cpu_to_node() being passed to kmalloc_node(), I think an
appropriate fix is to change that to cpu_to_mem()?
Yup.
Yeah, the default policy should be to fallback to local memory if the node
passed is memoryless.
Thanks!
I would
On Fri, Jan 24, 2014 at 05:10:42PM -0800, Nishanth Aravamudan wrote:
On 24.01.2014 [16:25:58 -0800], David Rientjes wrote:
On Fri, 24 Jan 2014, Nishanth Aravamudan wrote:
Thank you for clarifying and providing a test patch. I ran with this on
the system showing the original problem,
On Fri, 24 Jan 2014, Wanpeng Li wrote:
diff --git a/mm/slub.c b/mm/slub.c
index 545a170..a1c6040 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1700,6 +1700,9 @@ static void *get_partial(struct kmem_cache *s, gfp_t
flags, int node,
void *object;
int searchnode = (node ==
On 24.01.2014 [13:03:13 -0800], David Rientjes wrote:
On Fri, 24 Jan 2014, Christoph Lameter wrote:
On Fri, 24 Jan 2014, Wanpeng Li wrote:
diff --git a/mm/slub.c b/mm/slub.c
index 545a170..a1c6040 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1700,6 +1700,9 @@ static void
On 24.01.2014 [13:03:13 -0800], David Rientjes wrote:
On Fri, 24 Jan 2014, Christoph Lameter wrote:
On Fri, 24 Jan 2014, Wanpeng Li wrote:
diff --git a/mm/slub.c b/mm/slub.c
index 545a170..a1c6040 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1700,6 +1700,9 @@ static void
On 24.01.2014 [15:49:33 -0800], David Rientjes wrote:
On Fri, 24 Jan 2014, Nishanth Aravamudan wrote:
I think the problem is a memoryless node being used for kmalloc_node() so
we need to decide where to enforce node_present_pages(). __slab_alloc()
seems like the best candidate when
On 24.01.2014 [16:25:58 -0800], David Rientjes wrote:
On Fri, 24 Jan 2014, Nishanth Aravamudan wrote:
Thank you for clarifying and providing a test patch. I ran with this on
the system showing the original problem, configured to have 15GB of
memory.
With your patch after boot:
Hi Christoph,
On Mon, Jan 20, 2014 at 04:13:30PM -0600, Christoph Lameter wrote:
On Mon, 20 Jan 2014, Wanpeng Li wrote:
+ enum zone_type high_zoneidx = gfp_zone(flags);
+ if (!node_present_pages(searchnode)) {
+ zonelist = node_zonelist(searchnode, flags);
+
On Fri, Jan 24, 2014 at 11:09:07AM +0800, Wanpeng Li wrote:
Hi Christoph,
On Mon, Jan 20, 2014 at 04:13:30PM -0600, Christoph Lameter wrote:
On Mon, 20 Jan 2014, Wanpeng Li wrote:
+ enum zone_type high_zoneidx = gfp_zone(flags);
+ if (!node_present_pages(searchnode)) {
+
Hi Joonsoo,
On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
[...]
-8
diff --git a/mm/slub.c b/mm/slub.c
index c3eb3d3..a1f6dfa 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1672,7 +1672,19 @@ static void *get_partial(struct kmem_cache *s, gfp_t
flags,
On Mon, 20 Jan 2014, Wanpeng Li wrote:
+ enum zone_type high_zoneidx = gfp_zone(flags);
+ if (!node_present_pages(searchnode)) {
+ zonelist = node_zonelist(searchnode, flags);
+ for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
+
On Mon, Jan 20, 2014 at 04:13:30PM -0600, Christoph Lameter wrote:
On Mon, 20 Jan 2014, Wanpeng Li wrote:
+ enum zone_type high_zoneidx = gfp_zone(flags);
+ if (!node_present_pages(searchnode)) {
+ zonelist = node_zonelist(searchnode, flags);
+
Hi Andi,
Thoughts? It seems like we could hit a similar situation if a
machine is balanced but we run out of memory on a single node.
Yes I agree, but your patch doesn't seem to attempt to handle this?
It doesn't. I was hoping someone with more mm knowledge than I could
suggest a
Hi David,
Why not just delete the entire test?
Presumably some time a little earlier no local memory was available.
Even if there is some available now, it is very likely that some won't
be available again in the near future.
I agree, the current behaviour seems strange but it has been
Hi Wanpeng,
+if (node_spanned_pages(node)) {
s/node_spanned_pages/node_present_pages
Thanks, I hadn't come across node_present_pages() before.
Anton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On Tue, Jan 07, 2014 at 05:52:31PM +0800, Wanpeng Li wrote:
On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
Index: b/mm/slub.c
===
--- a/mm/slub.c
Hi Joonsoo,
On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
[...]
Hello,
I think that we need more efforts to solve unbalanced node problem.
With this patch, even if node of current cpu slab is not favorable to
On Tue, Jan 07, 2014 at 06:10:16PM +0900, Joonsoo Kim wrote:
On Tue, Jan 07, 2014 at 04:48:40PM +0800, Wanpeng Li wrote:
Hi Joonsoo,
On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
[...]
Hello,
I think that we
On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
We noticed a huge amount of slab memory consumed on a large ppc64 box:
Slab:2094336 kB
Almost 2GB. This box is not balanced and some nodes do not have local
memory, causing slub to be very inefficient in its
On Tue, Jan 07, 2014 at 04:48:40PM +0800, Wanpeng Li wrote:
Hi Joonsoo,
On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
[...]
Hello,
I think that we need more efforts to solve unbalanced node problem.
With
On Tue, Jan 07, 2014 at 05:21:45PM +0800, Wanpeng Li wrote:
On Tue, Jan 07, 2014 at 06:10:16PM +0900, Joonsoo Kim wrote:
On Tue, Jan 07, 2014 at 04:48:40PM +0800, Wanpeng Li wrote:
Hi Joonsoo,
On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
On Tue, Jan 07, 2014 at 01:21:00PM
On Tue, Jan 07, 2014 at 06:31:56PM +0900, Joonsoo Kim wrote:
On Tue, Jan 07, 2014 at 05:21:45PM +0800, Wanpeng Li wrote:
On Tue, Jan 07, 2014 at 06:10:16PM +0900, Joonsoo Kim wrote:
On Tue, Jan 07, 2014 at 04:48:40PM +0800, Wanpeng Li wrote:
Hi Joonsoo,
On Tue, Jan 07, 2014 at 04:41:36PM
From: Anton Blanchard
We noticed a huge amount of slab memory consumed on a large ppc64 box:
Slab:2094336 kB
Almost 2GB. This box is not balanced and some nodes do not have local
memory, causing slub to be very inefficient in its slab usage.
Each time we call
On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
We noticed a huge amount of slab memory consumed on a large ppc64 box:
Slab:2094336 kB
Almost 2GB. This box is not balanced and some nodes do not have
On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
We noticed a huge amount of slab memory consumed on a large ppc64 box:
Slab:2094336 kB
Almost 2GB. This box is not balanced and some nodes do not have local
memory, causing slub to be very inefficient in its slab
On Tue, Jan 07, 2014 at 01:21:00PM +1100, Anton Blanchard wrote:
We noticed a huge amount of slab memory consumed on a large ppc64 box:
Slab:2094336 kB
Almost 2GB. This box is not balanced and some nodes do not have local
memory, causing slub to be very inefficient in its slab
Anton Blanchard an...@samba.org writes:
Thoughts? It seems like we could hit a similar situation if a machine
is balanced but we run out of memory on a single node.
Yes I agree, but your patch doesn't seem to attempt to handle this?
-Andi
Index: b/mm/slub.c
43 matches
Mail list logo
