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],
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 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 hi
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:
> >
> > > Thank you for clarifying and providing a test patch. I ran with this on
> > > the system showing the original
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 i
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
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 loo
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 ca
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 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
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 ma
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 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 prev
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 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...
___
Lin
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 pat
On Fri, 24 Jan 2014, Nishanth Aravamudan wrote:
> What I find odd is that there are only 2 nodes on this system, node 0
> (empty) and node 1. So won't numa_mem_id() always be 1? And every page
> should be coming from node 1 (thus node_match() should always be true?)
Well yes that occurs if you sp
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, 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, 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
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
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 candi
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
> > > >@@ -17
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
> > > >@@ -17
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 =
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(searchnod
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, flag
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 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) {
> >+
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
>f
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
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
https://lists.ozlabs.
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 a
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 li
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 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
> 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 kmem_c
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 0
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
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 prob
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 i
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,
>>
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 t
Anton Blanchard 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
> ==
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
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 kmem_cache_alloc_node slub checks the per cpu
46 matches
Mail list logo
