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]
Date:   Fri, 12 Apr 2019 15:32:22 -0400
From:   Len Brown <>
To:     Peter Zijlstra <>
Cc:     X86 ML <>,
Subject: Re: [PATCH 0/14] v2 multi-die/package topology support

On Tue, Feb 26, 2019 at 1:51 PM Peter Zijlstra <> wrote:
> On Tue, Feb 26, 2019 at 01:19:58AM -0500, Len Brown wrote:
> > Restored sysfs core_siblings, core_siblings_list
> >
> >       v1 proposed re-defining this existing attribute to
> >       be the threads in a die, rather than in a package.
> >
> >       For compatibility, decided rather to keep this
> >       attribute unchanged, for now, even though
> >       its name makes little sense, and it makes
> >       no sense in a multi-die system.
> So why do things that make no sense?

>>> 7) /sys/devices/system/cpu/cpuX/topology/core_siblings:
>>> internal kernel map of cpuX's hardware threads within the same
>>> physical_package_id.

This definition tells you what cpus are in what package.
That is fine, it is useful, and it is in use.

What doesn't make sense is that it is called "core_siblings".
Who is to say that the map of CPUs inside a package has anything to do
with "cores"?
Sometimes it does, sometimes it doesn't...

> What breaks?

User space applications, such as lscpu and hwloc are using this attribute
per its definition, to figure out what cpus are in what packages.
If we change the definition to match the attribute's name, they break.
If we change the attribute name to match the definition, they break.

So the plan is to simply leave this attribute and its definition in place,
deprecate it, and move to the new attribute names that don't have
the word "siblings" in them -- which imply a known fixed topology.

We can schedule this attribute to be deleted some day,
but changing it and hoping you've updated all of user-space
would be a unnecessary pain.

Len Brown, Intel Open Source Technology Center

Powered by blists - more mailing lists