Re: [PATCH 2/8] numa: x86_64: use generic percpu var numa_node_id() implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2010-04-18 at 11:56 +0900, Tejun Heo wrote:
> On 04/17/2010 01:46 AM, Christoph Lameter wrote:
> > Maybe provide a generic function to set the node for cpu X?
> 
> Yeap, seconded.  Also, why not use numa_node_id() in
> common.c::cpu_init()?

Tejun:  do you mean:

#ifdef CONFIG_NUMA
        if (cpu != 0 && percpu_read(numa_node) == 0 &&
........................^ here?
            early_cpu_to_node(cpu) != NUMA_NO_NODE)
                set_numa_node(early_cpu_to_node(cpu));
#endif

Looks like 'numa_node_id()' would work there.

But, I wonder what the "cpu != 0 && percpu_read(numa_node) == 0" is
trying to do?

E.g., is "cpu != 0" testing "cpu != boot_cpu_id"?  Is there an implicit
assumption that the boot cpu is zero?  Or just a non-zero cpuid is
obviously initialized?

And the "percpu_read(numa_node) == 0" is testing that this cpu's
'numa_node' MAY not be initialized?  0 is a valid node id for !0 cpu
ids.  But it's OK to reinitialize numa_node in that case.

Just trying to grok the intent.  Maybe someone will chime in.

Anyway, if the intent is to test the percpu 'numa_node' for
initialization, using numa_node_id() might obscure this even more.

Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-numa" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]     [Devices]

  Powered by Linux