[lkml]   [2010]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCHSET] x86: unify x86_32 and 64 NUMA init paths, take#4
On 12/30/2010 09:49 AM, Tejun Heo wrote:
> 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%.


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

 \ /
  Last update: 2010-12-30 21:17    [W:0.106 / U:11.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site