lkml.org 
[lkml]   [2009]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/5 v4] x86: Adapt CPU topology detection for AMD Magny-Cours
    On Wed, Aug 05, 2009 at 10:23:54PM +0200, Brice Goglin wrote:
    > Andreas Herrmann wrote:
    > > Changes to previous patch set:
    > > - fixed allnoconfig compile error and link error if CONFIG_PCI=n
    > > - fixed hotplug issue: cpumask of siblings sharing same L3 were not
    > > properly updated
    > > - properly allocate cpu_node_map
    > >
    > > Current patch set contains 5 patches:
    > > - patch 1 adapts common code to show cpu_node_id,
    > > cpu_node_siblings and cpu_node_siblings_list in
    > > /sys/devices/system/cpu/cpu*/topology
    > > - patch 2 prepares arch/x86 to provide cpu_node information
    > > - patch 3 sets up cpu_node information for AMD Magny-Cours CPU
    > > - patch 4 fixes L3 cache information for Magny-Cours
    > > - patch 5 fixes mcheck code for Magny-Cours
    > >
    >
    > Hello Andreas,
    >
    > Reading your first submission I find something disturbing. You say that
    > we'll have the following sibling information:
    >
    > Level | Set of CPUs
    > --------------|---------------
    > phys_package | core_siblings
    > cpu_node | cpu_node_siblings
    > core | thread_siblings
    > thread | one CPU

    > This breaks the existing convention/semantics.

    Isn't the existing convention that core_siblings denotes all CPUs on
    same socket.

    > Currently core/thread_siblings contains the cpumask covering *all*
    > siblings of current core/thread object. What you're adding only
    > shows the cpumask of current "cpu_node" object in
    > cpu_node_siblings. I don't have any preference between both
    > semantics, but I think "cpu_node" should use the semantics that
    > "core" and "thread" do. So the above should be changed into:

    > Level | Set of CPUs
    > --------------|---------------
    > phys_package | cpu_node_siblings
    > cpu_node | core_siblings
    > core | thread_siblings
    > thread | one CPU

    Of course I thought also to implement it this way because it looks
    more consistent, but IMHO the patches are less intrusive if this
    scheme is _not_ used. Instead I kept core_siblings as is ("for
    historic reasons", nobody needs to accustom to new semantics). And use
    cpu_node_siblings where it really matters.

    But this reminds me that some documentation is required to describe
    the new attributes.

    What do others think?


    Thanks,
    Andreas

    --
    Operating | Advanced Micro Devices GmbH
    System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
    Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
    Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
    (OSRC) | Registergericht München, HRB Nr. 43632


    --
    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/

    \
     
     \ /
      Last update: 2009-08-06 12:45    [W:0.048 / U:0.940 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site