lkml.org 
[lkml]   [2010]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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%.

-hpa

--
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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site