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: <20201006085152.tro3cypebbyw4ng7@e107158-lin.cambridge.arm.com>
Date:   Tue, 6 Oct 2020 09:51:53 +0100
From:   Qais Yousef <qais.yousef@....com>
To:     Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>, x86@...nel.org,
        Borislav Petkov <bp@...e.de>, Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Len Brown <len.brown@...el.com>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        linux-kernel@...r.kernel.org,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Quentin Perret <qperret@...gle.com>
Subject: Re: [PATCH 0/4] drivers core: Introduce CPU type sysfs interface

Hi Ricardo

Adding some people who might be interested.

On 10/02/20 18:17, Ricardo Neri wrote:
> Hybrid CPU topologies combine processors with more than one type of
> micro-architecture. Hence, it is possible that individual CPUs support
> slightly different features (e.g., performance counters) and different
> performance properties. Thus, there may be user space entities interested
> in knowing the topology of the system based on the types of available
> CPUs.
> 
> Currently, there exists an interface for the CPU capacity (/sys/devices/
> system/cpu/cpuX/cpu_capacity). However, CPU capacity does not always map
> to CPU types (by the way, I will submit a separate series to bring such
> interface to x86).

Why do you need to do this mapping?

> 
> This series proposes the new interface /sys/devices/system/cpu/types
> which, in hybrid parts, creates a subdirectory for each type of CPU.
> Each subdirectory contains a CPU list and a CPU map that user space can
> query.

Why user space needs to query this info?

The rationale is missing the intention behind all of this. It seems you're
expecting software to parse this info and take decisions based on that?

Thanks

--
Qais Yousef

> 
> Patch 1 of the series proposes the generic interface, with hooks
> that architectures can override to suit their needs. The three patches
> patches implement such interface for x86 (as per request from Boris,
> I pulled patch 2 from a separate submission [1]).
> 
> Thanks and BR,
> Ricardo
> 
> [1]. https://lkml.org/lkml/2020/10/2/1013
> 
> Ricardo Neri (4):
>   drivers core: Introduce CPU type sysfs interface
>   x86/cpu: Describe hybrid CPUs in cpuinfo_x86
>   x86/cpu/intel: Add function to get name of hybrid CPU types
>   x86/cpu/topology: Implement the CPU type sysfs interface
> 
>  .../ABI/testing/sysfs-devices-system-cpu      |  13 ++
>  arch/x86/include/asm/intel-family.h           |   4 +
>  arch/x86/include/asm/processor.h              |  13 ++
>  arch/x86/include/asm/topology.h               |   2 +
>  arch/x86/kernel/cpu/common.c                  |   3 +
>  arch/x86/kernel/cpu/cpu.h                     |   3 +
>  arch/x86/kernel/cpu/intel.c                   |  23 ++
>  arch/x86/kernel/cpu/topology.c                |  23 ++
>  drivers/base/cpu.c                            | 214 ++++++++++++++++++
>  include/linux/cpu.h                           |  12 +
>  include/linux/cpuhotplug.h                    |   1 +
>  11 files changed, 311 insertions(+)
> 
> -- 
> 2.17.1
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ