On 15.07.2015 [16:35:16 -0400], Tejun Heo wrote:
Hello,
On Thu, Jul 02, 2015 at 04:02:02PM -0700, Nishanth Aravamudan wrote:
we currently emit at boot:
[0.00] pcpu-alloc: [0] 0 1 2 3 [0] 4 5 6 7
After this commit, we correctly emit:
[0.00] pcpu-alloc: [0] 0 1
Hello,
On Wed, Jul 15, 2015 at 03:43:51PM -0700, Nishanth Aravamudan wrote:
Ok, thank you for clarifying! From a correctness perspective, even if
the numbers don't match NUMA nodes, should we expect the grouping to be
split along NUMA topology?
Yeap, the groups get formed according to the
Hello,
On Thu, Jul 02, 2015 at 04:02:02PM -0700, Nishanth Aravamudan wrote:
we currently emit at boot:
[0.00] pcpu-alloc: [0] 0 1 2 3 [0] 4 5 6 7
After this commit, we correctly emit:
[0.00] pcpu-alloc: [0] 0 1 2 3 [1] 4 5 6 7
JFYI, the numbers in the brackets aren't
On Fri, 10 Jul 2015, Nishanth Aravamudan wrote:
After the percpu areas on initialized and cpu_to_node() is correct, it
would be really nice to be able to make numa_cpu_lookup_table[] be
__initdata since it shouldn't be necessary anymore. That probably has cpu
callbacks that need to be
On 08.07.2015 [18:22:09 -0700], David Rientjes wrote:
On Thu, 2 Jul 2015, Nishanth Aravamudan wrote:
Much like on x86, now that powerpc is using USE_PERCPU_NUMA_NODE_ID, we
have an ordering issue during boot with early calls to cpu_to_node().
The value returned by those calls now depend
On Thu, 2 Jul 2015, Nishanth Aravamudan wrote:
Much like on x86, now that powerpc is using USE_PERCPU_NUMA_NODE_ID, we
have an ordering issue during boot with early calls to cpu_to_node().
The value returned by those calls now depend on the per-cpu area being
setup, but that is not guaranteed
Much like on x86, now that powerpc is using USE_PERCPU_NUMA_NODE_ID, we
have an ordering issue during boot with early calls to cpu_to_node().
The value returned by those calls now depend on the per-cpu area being
setup, but that is not guaranteed to be the case during boot. Instead,
we need to add
