[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.033 / U:65.724 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site