From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> To: Christoph Lameter <cl@linux.com> Cc: Han Pingtian <hanpt@linux.vnet.ibm.com>, mpm@selenic.com, penberg@kernel.org, linux-mm@kvack.org, paulus@samba.org, Anton Blanchard <anton@samba.org>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, linuxppc-dev@lists.ozlabs.org, Wanpeng Li <liwanp@linux.vnet.ibm.com> Subject: Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory Date: Wed, 5 Feb 2014 18:08:33 -0800 [thread overview] Message-ID: <20140206020833.GD5433@linux.vnet.ibm.com> (raw) In-Reply-To: <alpine.DEB.2.10.1402051312430.21661@nuc> 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 current cpu slab. A more > > > complex solution would be to look through partial lists in increasing > > > distance to find a partially used slab that is reasonable close to the > > > current node. Slab has logic like that in fallback_alloc(). Slubs > > > get_any_partial() function does something close to what you want. > > > > I apologize for my own ignorance, but I'm having trouble following. > > Anton's original patch did fallback to the current cpu slab, but I'm not > > sure any NUMA_NO_NODE change is necessary there. At the point we're > > deactivating the slab (in the current code, in __slab_alloc()), we have > > successfully allocated from somewhere, it's just not on the node we > > expected to be on. > > 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? > > So perhaps you are saying to make a change lower in the code? I'm not > > sure where it makes sense to change the target node in that case. I'd > > appreciate any guidance you can give. > > This not an easy thing to do. If the current slab is not the right node > but would be the node from which the page allocator would be returning > memory then the current slab can still be allocated from. If the fallback > is to another node then the current cpu slab needs to be deactivated and > the allocation from that node needs to proceeed. Have a look at > fallback_alloc() in the slab allocator. > > A allocation attempt from the page allocator can be restricted to a > specific node through GFP_THIS_NODE. Thanks for the pointers, I will try and take a look. 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: Christoph Lameter <cl@linux.com> Cc: Han Pingtian <hanpt@linux.vnet.ibm.com>, David Rientjes <rientjes@google.com>, penberg@kernel.org, linux-mm@kvack.org, paulus@samba.org, Anton Blanchard <anton@samba.org>, mpm@selenic.com, Joonsoo Kim <iamjoonsoo.kim@lge.com>, linuxppc-dev@lists.ozlabs.org, Wanpeng Li <liwanp@linux.vnet.ibm.com> Subject: Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory Date: Wed, 5 Feb 2014 18:08:33 -0800 [thread overview] Message-ID: <20140206020833.GD5433@linux.vnet.ibm.com> (raw) In-Reply-To: <alpine.DEB.2.10.1402051312430.21661@nuc> 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 current cpu slab. A more > > > complex solution would be to look through partial lists in increasing > > > distance to find a partially used slab that is reasonable close to the > > > current node. Slab has logic like that in fallback_alloc(). Slubs > > > get_any_partial() function does something close to what you want. > > > > I apologize for my own ignorance, but I'm having trouble following. > > Anton's original patch did fallback to the current cpu slab, but I'm not > > sure any NUMA_NO_NODE change is necessary there. At the point we're > > deactivating the slab (in the current code, in __slab_alloc()), we have > > successfully allocated from somewhere, it's just not on the node we > > expected to be on. > > 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? > > So perhaps you are saying to make a change lower in the code? I'm not > > sure where it makes sense to change the target node in that case. I'd > > appreciate any guidance you can give. > > This not an easy thing to do. If the current slab is not the right node > but would be the node from which the page allocator would be returning > memory then the current slab can still be allocated from. If the fallback > is to another node then the current cpu slab needs to be deactivated and > the allocation from that node needs to proceeed. Have a look at > fallback_alloc() in the slab allocator. > > A allocation attempt from the page allocator can be restricted to a > specific node through GFP_THIS_NODE. Thanks for the pointers, I will try and take a look. Thanks, Nish
next prev parent reply other threads:[~2014-02-06 2:09 UTC|newest] Thread overview: 229+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-01-07 2:21 [PATCH] slub: Don't throw away partial remote slabs if there is no local memory Anton Blanchard 2014-01-07 2:21 ` Anton Blanchard 2014-01-07 4:19 ` Wanpeng Li 2014-01-07 4:19 ` Wanpeng Li 2014-01-07 4:19 ` Wanpeng Li 2014-01-08 14:17 ` Anton Blanchard 2014-01-08 14:17 ` Anton Blanchard 2014-01-07 4:19 ` Wanpeng Li 2014-01-07 6:49 ` Andi Kleen 2014-01-07 6:49 ` Andi Kleen 2014-01-08 14:03 ` Anton Blanchard 2014-01-08 14:03 ` Anton Blanchard 2014-01-07 7:41 ` Joonsoo Kim 2014-01-07 7:41 ` Joonsoo Kim 2014-01-07 8:48 ` Wanpeng Li 2014-01-07 8:48 ` Wanpeng Li 2014-01-07 8:48 ` Wanpeng Li 2014-01-07 8:48 ` Wanpeng Li 2014-01-07 9:10 ` Joonsoo Kim 2014-01-07 9:10 ` Joonsoo Kim 2014-01-07 9:21 ` Wanpeng Li 2014-01-07 9:21 ` Wanpeng Li 2014-01-07 9:31 ` Joonsoo Kim 2014-01-07 9:31 ` Joonsoo Kim 2014-01-07 9:49 ` Wanpeng Li 2014-01-07 9:49 ` Wanpeng Li 2014-01-07 9:49 ` Wanpeng Li 2014-01-07 9:49 ` Wanpeng Li 2014-01-07 9:21 ` Wanpeng Li 2014-01-07 9:21 ` Wanpeng Li 2014-01-07 9:52 ` Wanpeng Li 2014-01-07 9:52 ` Wanpeng Li 2014-01-07 9:52 ` Wanpeng Li 2014-01-09 0:20 ` Joonsoo Kim 2014-01-09 0:20 ` Joonsoo Kim 2014-01-07 9:52 ` Wanpeng Li 2014-01-20 9:10 ` Wanpeng Li 2014-01-20 9:10 ` Wanpeng Li 2014-01-20 9:10 ` Wanpeng Li 2014-01-20 9:10 ` Wanpeng Li [not found] ` <52dce7fe.e5e6420a.5ff6.ffff84a0SMTPIN_ADDED_BROKEN@mx.google.com> 2014-01-20 22:13 ` Christoph Lameter 2014-01-20 22:13 ` Christoph Lameter 2014-01-21 2:20 ` Wanpeng Li 2014-01-21 2:20 ` Wanpeng Li 2014-01-21 2:20 ` Wanpeng Li 2014-01-21 2:20 ` Wanpeng Li 2014-01-24 3:09 ` Wanpeng Li 2014-01-24 3:09 ` Wanpeng Li 2014-01-24 3:09 ` Wanpeng Li 2014-01-24 3:09 ` Wanpeng Li 2014-01-24 3:14 ` Wanpeng Li 2014-01-24 3:14 ` Wanpeng Li 2014-01-24 3:14 ` Wanpeng Li 2014-01-24 3:14 ` Wanpeng Li [not found] ` <52e1da8f.86f7440a.120f.25f3SMTPIN_ADDED_BROKEN@mx.google.com> 2014-01-24 15:50 ` Christoph Lameter 2014-01-24 15:50 ` Christoph Lameter 2014-01-24 21:03 ` David Rientjes 2014-01-24 21:03 ` David Rientjes 2014-01-24 22:19 ` Nishanth Aravamudan 2014-01-24 22:19 ` Nishanth Aravamudan 2014-01-24 23:29 ` Nishanth Aravamudan 2014-01-24 23:29 ` Nishanth Aravamudan 2014-01-24 23:49 ` David Rientjes 2014-01-24 23:49 ` David Rientjes 2014-01-25 0:16 ` Nishanth Aravamudan 2014-01-25 0:16 ` Nishanth Aravamudan 2014-01-25 0:25 ` David Rientjes 2014-01-25 0:25 ` David Rientjes 2014-01-25 1:10 ` Nishanth Aravamudan 2014-01-25 1:10 ` Nishanth Aravamudan 2014-01-27 5:58 ` Joonsoo Kim 2014-01-27 5:58 ` Joonsoo Kim 2014-01-28 18:29 ` Nishanth Aravamudan 2014-01-28 18:29 ` Nishanth Aravamudan 2014-01-29 15:54 ` Christoph Lameter 2014-01-29 15:54 ` Christoph Lameter 2014-01-29 22:36 ` Nishanth Aravamudan 2014-01-29 22:36 ` Nishanth Aravamudan 2014-01-30 16:26 ` Christoph Lameter 2014-01-30 16:26 ` Christoph Lameter 2014-02-03 23:00 ` Nishanth Aravamudan 2014-02-03 23:00 ` Nishanth Aravamudan 2014-02-04 3:38 ` Christoph Lameter 2014-02-04 3:38 ` Christoph Lameter 2014-02-04 7:26 ` Nishanth Aravamudan 2014-02-04 7:26 ` Nishanth Aravamudan 2014-02-04 20:39 ` Christoph Lameter 2014-02-04 20:39 ` Christoph Lameter 2014-02-05 0:13 ` Nishanth Aravamudan 2014-02-05 0:13 ` Nishanth Aravamudan 2014-02-05 19:28 ` Christoph Lameter 2014-02-05 19:28 ` Christoph Lameter 2014-02-06 2:08 ` Nishanth Aravamudan [this message] 2014-02-06 2:08 ` Nishanth Aravamudan 2014-02-06 17:25 ` Christoph Lameter 2014-02-06 17:25 ` Christoph Lameter 2014-01-27 16:18 ` Christoph Lameter 2014-01-27 16:18 ` Christoph Lameter 2014-02-06 2:07 ` Nishanth Aravamudan 2014-02-06 2:07 ` Nishanth Aravamudan 2014-02-06 8:04 ` Joonsoo Kim 2014-02-06 8:04 ` Joonsoo Kim [not found] ` <20140206185955.GA7845@linux.vnet.ibm.com> 2014-02-06 19:28 ` Nishanth Aravamudan 2014-02-06 19:28 ` Nishanth Aravamudan 2014-02-07 8:03 ` Joonsoo Kim 2014-02-07 8:03 ` Joonsoo Kim 2014-02-06 8:07 ` [RFC PATCH 1/3] slub: search partial list on numa_mem_id(), instead of numa_node_id() Joonsoo Kim 2014-02-06 8:07 ` Joonsoo Kim 2014-02-06 8:07 ` [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node Joonsoo Kim 2014-02-06 8:07 ` Joonsoo Kim 2014-02-06 8:52 ` David Rientjes 2014-02-06 8:52 ` David Rientjes 2014-02-06 10:29 ` Joonsoo Kim 2014-02-06 10:29 ` Joonsoo Kim 2014-02-06 19:11 ` Nishanth Aravamudan 2014-02-06 19:11 ` Nishanth Aravamudan 2014-02-07 5:42 ` Joonsoo Kim 2014-02-07 5:42 ` Joonsoo Kim 2014-02-06 20:52 ` David Rientjes 2014-02-06 20:52 ` David Rientjes 2014-02-07 5:48 ` Joonsoo Kim 2014-02-07 5:48 ` Joonsoo Kim 2014-02-07 17:53 ` Christoph Lameter 2014-02-07 17:53 ` Christoph Lameter 2014-02-07 18:51 ` Christoph Lameter 2014-02-07 18:51 ` Christoph Lameter 2014-02-07 21:38 ` Nishanth Aravamudan 2014-02-07 21:38 ` Nishanth Aravamudan 2014-02-10 1:15 ` Joonsoo Kim 2014-02-10 1:15 ` Joonsoo Kim 2014-02-10 1:29 ` Joonsoo Kim 2014-02-10 1:29 ` Joonsoo Kim 2014-02-11 18:45 ` Christoph Lameter 2014-02-11 18:45 ` Christoph Lameter 2014-02-10 19:13 ` Nishanth Aravamudan 2014-02-10 19:13 ` Nishanth Aravamudan 2014-02-11 7:42 ` Joonsoo Kim 2014-02-11 7:42 ` Joonsoo Kim 2014-02-12 22:16 ` Christoph Lameter 2014-02-12 22:16 ` Christoph Lameter 2014-02-13 3:53 ` Nishanth Aravamudan 2014-02-13 3:53 ` Nishanth Aravamudan 2014-02-17 6:52 ` Joonsoo Kim 2014-02-17 6:52 ` Joonsoo Kim 2014-02-18 16:38 ` Christoph Lameter 2014-02-18 16:38 ` Christoph Lameter 2014-02-19 22:04 ` David Rientjes 2014-02-19 22:04 ` David Rientjes 2014-02-20 16:02 ` Christoph Lameter 2014-02-20 16:02 ` Christoph Lameter 2014-02-24 5:08 ` Joonsoo Kim 2014-02-24 5:08 ` Joonsoo Kim 2014-02-24 19:54 ` Christoph Lameter 2014-02-24 19:54 ` Christoph Lameter 2014-03-13 16:51 ` Nishanth Aravamudan 2014-03-13 16:51 ` Nishanth Aravamudan 2014-02-18 17:22 ` Nishanth Aravamudan 2014-02-18 17:22 ` Nishanth Aravamudan 2014-02-13 6:51 ` Nishanth Aravamudan 2014-02-13 6:51 ` Nishanth Aravamudan 2014-02-17 7:00 ` Joonsoo Kim 2014-02-17 7:00 ` Joonsoo Kim 2014-02-18 16:57 ` Christoph Lameter 2014-02-18 16:57 ` Christoph Lameter 2014-02-18 17:28 ` Nishanth Aravamudan 2014-02-18 17:28 ` Nishanth Aravamudan 2014-02-18 19:58 ` Christoph Lameter 2014-02-18 19:58 ` Christoph Lameter 2014-02-18 21:09 ` Nishanth Aravamudan 2014-02-18 21:09 ` Nishanth Aravamudan 2014-02-18 21:49 ` Christoph Lameter 2014-02-18 21:49 ` Christoph Lameter 2014-02-18 22:22 ` Nishanth Aravamudan 2014-02-18 22:22 ` Nishanth Aravamudan 2014-02-19 16:11 ` Christoph Lameter 2014-02-19 16:11 ` Christoph Lameter 2014-02-19 22:03 ` David Rientjes 2014-02-19 22:03 ` David Rientjes 2014-02-08 9:57 ` David Rientjes 2014-02-08 9:57 ` David Rientjes 2014-02-10 1:09 ` Joonsoo Kim 2014-02-10 1:09 ` Joonsoo Kim 2014-07-22 1:03 ` Nishanth Aravamudan 2014-07-22 1:03 ` Nishanth Aravamudan 2014-07-22 1:16 ` David Rientjes 2014-07-22 1:16 ` David Rientjes 2014-07-22 21:43 ` Nishanth Aravamudan 2014-07-22 21:43 ` Nishanth Aravamudan 2014-07-22 21:49 ` Tejun Heo 2014-07-22 21:49 ` Tejun Heo 2014-07-22 23:47 ` Nishanth Aravamudan 2014-07-22 23:47 ` Nishanth Aravamudan 2014-07-23 0:43 ` David Rientjes 2014-07-23 0:43 ` David Rientjes 2014-02-06 8:07 ` [RFC PATCH 3/3] slub: fallback to get_numa_mem() node if we want to allocate on memoryless node Joonsoo Kim 2014-02-06 8:07 ` Joonsoo Kim 2014-02-06 17:30 ` Christoph Lameter 2014-02-06 17:30 ` Christoph Lameter 2014-02-07 5:41 ` Joonsoo Kim 2014-02-07 5:41 ` Joonsoo Kim 2014-02-07 17:49 ` Christoph Lameter 2014-02-07 17:49 ` Christoph Lameter 2014-02-10 1:22 ` Joonsoo Kim 2014-02-10 1:22 ` Joonsoo Kim 2014-02-06 8:37 ` [RFC PATCH 1/3] slub: search partial list on numa_mem_id(), instead of numa_node_id() David Rientjes 2014-02-06 8:37 ` David Rientjes 2014-02-06 17:31 ` Christoph Lameter 2014-02-06 17:31 ` Christoph Lameter 2014-02-06 17:26 ` Christoph Lameter 2014-02-06 17:26 ` Christoph Lameter 2014-05-16 23:37 ` Nishanth Aravamudan 2014-05-16 23:37 ` Nishanth Aravamudan 2014-05-19 2:41 ` Joonsoo Kim 2014-05-19 2:41 ` Joonsoo Kim 2014-06-05 0:13 ` [RESEND PATCH] " David Rientjes 2014-06-05 0:13 ` David Rientjes 2014-06-05 0:13 ` David Rientjes 2014-01-27 16:24 ` [PATCH] slub: Don't throw away partial remote slabs if there is no local memory Christoph Lameter 2014-01-27 16:24 ` Christoph Lameter 2014-01-27 16:16 ` Christoph Lameter 2014-01-27 16:16 ` Christoph Lameter 2014-01-07 9:42 ` David Laight 2014-01-07 9:42 ` David Laight 2014-01-08 14:14 ` Anton Blanchard 2014-01-08 14:14 ` Anton Blanchard 2014-01-07 10:28 ` Wanpeng Li 2014-01-07 10:28 ` Wanpeng Li 2014-01-07 10:28 ` Wanpeng Li 2014-01-07 10:28 ` Wanpeng Li
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=20140206020833.GD5433@linux.vnet.ibm.com \ --to=nacc@linux.vnet.ibm.com \ --cc=anton@samba.org \ --cc=cl@linux.com \ --cc=hanpt@linux.vnet.ibm.com \ --cc=iamjoonsoo.kim@lge.com \ --cc=linux-mm@kvack.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=liwanp@linux.vnet.ibm.com \ --cc=mpm@selenic.com \ --cc=paulus@samba.org \ --cc=penberg@kernel.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: linkBe 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.