lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJvTdK=SGZy+vbTcCKAmBeQSkeuAW0UxEpKXY2YNvmUofFXNUQ@mail.gmail.com>
Date:   Tue, 30 Apr 2019 02:50:58 -0400
From:   Len Brown <lenb@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     X86 ML <x86@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/14] v2 multi-die/package topology support

On Tue, Feb 26, 2019 at 2:05 PM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Tue, Feb 26, 2019 at 01:19:58AM -0500, Len Brown wrote:
> >  Documentation/cputopology.txt                | 72 ++++++++++++++---------
> >  Documentation/x86/topology.txt               |  6 +-
> >  arch/x86/include/asm/processor.h             |  5 +-
> >  arch/x86/include/asm/smp.h                   |  1 +
> >  arch/x86/include/asm/topology.h              |  5 ++
> >  arch/x86/kernel/cpu/topology.c               | 85 +++++++++++++++++++++-------
> >  arch/x86/kernel/smpboot.c                    | 73 +++++++++++++++++++++++-
> >  arch/x86/xen/smp_pv.c                        |  1 +
> >  drivers/base/topology.c                      | 22 +++++++
> >  drivers/hwmon/coretemp.c                     |  9 +--
> >  drivers/powercap/intel_rapl.c                | 75 +++++++++++++-----------
> >  drivers/thermal/intel/x86_pkg_temp_thermal.c |  9 +--
> >  include/linux/topology.h                     |  6 ++
> >  13 files changed, 276 insertions(+), 93 deletions(-)
>
> Should we not also have changes to
> arch/x86/kernel/cpu/proc.c:show_cpuinfo_cores() ?

Good question.
I was thinking that /proc/cpuinfo was sort of the legacy API, and
adding a field might break something.
While adding an attribute to sysfs topology directory was the
compatible/safe way to make additions.

/proc/cpuinfo has these fields today:

physical id : 0
    this is the physical package id
siblings : 8
    this is the count of cpus in the same package
core id : 3
    this is cpu_core_id
cpu cores : 4
    this is booted_cores

If one were to make a change here, I'd consider adding the (physical) die_id,
though it is already in sysfs topology as an attribute.

Not sure if it would then make sense to print the count of cpus in the die.
Not sure what I'd name it, and this info is already in sysfs as a map and list.


Len Brown, Intel Open Source Technology Center

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ