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 n
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
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 a
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 nee
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 d
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 guarant
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
