On 12/30/2010 09:49 AM, Tejun Heo wrote:
quoted text
> 
> The only change from the last take[L] is that it's now based on
> tip/x86/numa.  Unfortunately, some of the collisions weren't trivial
> and led to some ugliness.
> 
> Commit c1c3443c ("x86, numa: Fake node-to-cpumask for NUMA emulation")
> introduced hard dependency on x86_64 into numa_add/remove_cpu() when
> CONFIG_NUMA_EMU is enabled.  0015 has been updated so that the 32/64
> bit common versions used when !CONFIG_NUMA_EMU are in numa.c while
> CONFIG_NUMA_EMU variants are in numa_64.c.
> 
> This is ugly but still better than before.  IIUC, Shaohui's patchsets
> is going to unify NUMA emulation across 32 and 64bit, which should
> remove the above ugliness.  I haven't looked through the patchset yet
> but after skimming through the current NUMA_EMU code, here are some of
> my thoughts, FWIW.
> 
> * There's no reason for different NUMA config methods to construct
>   different data structures.  They all, including 32bit, can build a
>   single set of data structures.
> 
> * Then, unification of NUMA_EMU would naturally follow.  There's no
>   reason to think about whether the underlying NUMA and proximity
>   information is provided by ACPI, AMD or whatever.  It just needs to
>   manipulate the processed data.
> 
> Let's _please_ head that way instead of adding more gluing codes and
> hacks everywhere.  It would be a bit more churn but I don't think
> there's any other sustainable way.
> 

Agreed 100%.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/