Based off 3bccd996 for ia64, convert powerpc to use the generic per-CPU
topology tracking, specifically:
initialize per cpu numa_node entry in start_secondary
remove the powerpc cpu_to_node()
define CONFIG_USE_PERCPU_NUMA_NODE_ID if NUMA
Signed-off-by: Nishanth Aravamudan <redacted>
Hi Andrew,
I found one issue with my patch, fixed below...
On 16.05.2014 [16:39:45 -0700], Nishanth Aravamudan wrote:
Based off 3bccd996 for ia64, convert powerpc to use the generic per-CPU
topology tracking, specifically:
initialize per cpu numa_node entry in start_secondary
remove the powerpc cpu_to_node()
define CONFIG_USE_PERCPU_NUMA_NODE_ID if NUMA
Signed-off-by: Nishanth Aravamudan <redacted>
Similar change is needed for the boot CPU. Update patch:
powerpc: numa: enable USE_PERCPU_NUMA_NODE_ID
Based off 3bccd996 for ia64, convert powerpc to use the generic per-CPU
topology tracking, specifically:
initialize per cpu numa_node entry in start_secondary
remove the powerpc cpu_to_node()
define CONFIG_USE_PERCPU_NUMA_NODE_ID if NUMA
Signed-off-by: Nishanth Aravamudan <redacted>
On 19.05.2014 [11:14:23 -0700], Nishanth Aravamudan wrote:
Hi Andrew,
I found one issue with my patch, fixed below...
On 16.05.2014 [16:39:45 -0700], Nishanth Aravamudan wrote:
quoted
Based off 3bccd996 for ia64, convert powerpc to use the generic per-CPU
topology tracking, specifically:
initialize per cpu numa_node entry in start_secondary
remove the powerpc cpu_to_node()
define CONFIG_USE_PERCPU_NUMA_NODE_ID if NUMA
Signed-off-by: Nishanth Aravamudan <redacted>
Similar change is needed for the boot CPU. Update patch:
powerpc: numa: enable USE_PERCPU_NUMA_NODE_ID
Based off 3bccd996 for ia64, convert powerpc to use the generic per-CPU
topology tracking, specifically:
initialize per cpu numa_node entry in start_secondary
remove the powerpc cpu_to_node()
define CONFIG_USE_PERCPU_NUMA_NODE_ID if NUMA
Signed-off-by: Nishanth Aravamudan <redacted>
Ping on this and patch 2/2. Ben, would you be willing to pull these into
your -next branch so they'd get some testing?
http://patchwork.ozlabs.org/patch/350368/http://patchwork.ozlabs.org/patch/349838/
Without any further changes, these two help quite a bit with the slab
consumption on CONFIG_SLUB kernels when memoryless nodes are present.
Thanks,
Nish
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2014-05-27 23:56:35
On Tue, 2014-05-27 at 16:44 -0700, Nishanth Aravamudan wrote:
quoted
Signed-off-by: Nishanth Aravamudan <redacted>
Ping on this and patch 2/2. Ben, would you be willing to pull these
into
your -next branch so they'd get some testing?
http://patchwork.ozlabs.org/patch/350368/http://patchwork.ozlabs.org/patch/349838/
Without any further changes, these two help quite a bit with the slab
consumption on CONFIG_SLUB kernels when memoryless nodes are present.
I don't mind at all :-) I haven't really been following that story
so I was waiting for the dust to settle and maybe acks from MM people
but if you tell me they are good I'm prepared to trust you.
Cheers,
Ben.
On 28.05.2014 [09:56:14 +1000], Benjamin Herrenschmidt wrote:
On Tue, 2014-05-27 at 16:44 -0700, Nishanth Aravamudan wrote:
quoted
quoted
Signed-off-by: Nishanth Aravamudan <redacted>
Ping on this and patch 2/2. Ben, would you be willing to pull these
into
your -next branch so they'd get some testing?
http://patchwork.ozlabs.org/patch/350368/http://patchwork.ozlabs.org/patch/349838/
Without any further changes, these two help quite a bit with the slab
consumption on CONFIG_SLUB kernels when memoryless nodes are present.
I don't mind at all :-) I haven't really been following that story
so I was waiting for the dust to settle and maybe acks from MM people
but if you tell me they are good I'm prepared to trust you.
The patches themselves are pretty minimal and similar to the ia64
changes (and the affected code seems like it hasn't changed in some
time, beyond in the common code). I'd mostly like to get some
broad-range build & boot testing.
Also, is NUMA a sufficient symbol to depend, you think? I figure most of
the PPC NUMA systems are the pSeries/IBM variety, which is where I've
run into memoryless nodes in the first place.
Thanks,
Nish
From: Andrew Morton <akpm@linux-foundation.org> Date: 2014-05-28 23:36:10
On Tue, 27 May 2014 17:09:58 -0700 Nishanth Aravamudan [off-list ref] wrote:
On 28.05.2014 [09:56:14 +1000], Benjamin Herrenschmidt wrote:
quoted
On Tue, 2014-05-27 at 16:44 -0700, Nishanth Aravamudan wrote:
quoted
quoted
Signed-off-by: Nishanth Aravamudan <redacted>
Ping on this and patch 2/2. Ben, would you be willing to pull these
into
your -next branch so they'd get some testing?
http://patchwork.ozlabs.org/patch/350368/http://patchwork.ozlabs.org/patch/349838/
Without any further changes, these two help quite a bit with the slab
consumption on CONFIG_SLUB kernels when memoryless nodes are present.
I don't mind at all :-) I haven't really been following that story
so I was waiting for the dust to settle and maybe acks from MM people
but if you tell me they are good I'm prepared to trust you.
The patches themselves are pretty minimal and similar to the ia64
changes (and the affected code seems like it hasn't changed in some
time, beyond in the common code). I'd mostly like to get some
broad-range build & boot testing.
Also, is NUMA a sufficient symbol to depend, you think? I figure most of
the PPC NUMA systems are the pSeries/IBM variety, which is where I've
run into memoryless nodes in the first place.
It's a powerpc-only patchset so I didn't do anything.
Nits:
- When referring to git commits, use 12 digits of hash and include
the name of the patch as well (because patches can have different
hashes in different trees). So
Based on 3bccd996276b ("numa: ia64: use generic percpu
var numa_node_id() implementation") for ia64.
- It's nice to include a diffstat. If there's a [0/n] patch then
that's a great place for it, so people can see the overall impact at
a glance.
On 28.05.2014 [16:36:07 -0700], Andrew Morton wrote:
On Tue, 27 May 2014 17:09:58 -0700 Nishanth Aravamudan [off-list ref] wrote:
quoted
On 28.05.2014 [09:56:14 +1000], Benjamin Herrenschmidt wrote:
quoted
On Tue, 2014-05-27 at 16:44 -0700, Nishanth Aravamudan wrote:
quoted
quoted
Signed-off-by: Nishanth Aravamudan <redacted>
Ping on this and patch 2/2. Ben, would you be willing to pull these
into
your -next branch so they'd get some testing?
http://patchwork.ozlabs.org/patch/350368/http://patchwork.ozlabs.org/patch/349838/
Without any further changes, these two help quite a bit with the slab
consumption on CONFIG_SLUB kernels when memoryless nodes are present.
I don't mind at all :-) I haven't really been following that story
so I was waiting for the dust to settle and maybe acks from MM people
but if you tell me they are good I'm prepared to trust you.
The patches themselves are pretty minimal and similar to the ia64
changes (and the affected code seems like it hasn't changed in some
time, beyond in the common code). I'd mostly like to get some
broad-range build & boot testing.
Also, is NUMA a sufficient symbol to depend, you think? I figure most of
the PPC NUMA systems are the pSeries/IBM variety, which is where I've
run into memoryless nodes in the first place.
It's a powerpc-only patchset so I didn't do anything.
Nits:
- When referring to git commits, use 12 digits of hash and include
the name of the patch as well (because patches can have different
hashes in different trees). So
Based on 3bccd996276b ("numa: ia64: use generic percpu
var numa_node_id() implementation") for ia64.
- It's nice to include a diffstat. If there's a [0/n] patch then
that's a great place for it, so people can see the overall impact at
a glance.
Thanks for the notes, I'll include those in any updated patches.
-Nish