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
| ||
|
Message-ID: <CAJvTdK=DNUmOLb9QBHVxn_EAL33zisH-_ZPo8GfFa++5hrK5zQ@mail.gmail.com> Date: Fri, 12 Apr 2019 15:52:58 -0400 From: Len Brown <lenb@...nel.org> To: Thomas Gleixner <tglx@...utronix.de> Cc: Morten Rasmussen <morten.rasmussen@....com>, Peter Zijlstra <peterz@...radead.org>, X86 ML <x86@...nel.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH 0/14] v2 multi-die/package topology support > > > I think I prefer 's/threads/cpus/g' on that. Threads makes me think SMT, > > > and I don't think there's any guarantee the part in question will have > > > SMT on. > > > > I think 'threads' is a bit confusing as well. We seem to be using 'cpu' > > everywhere for something we can schedule tasks on, including the sysfs > > /sys/devices/system/cpu/ subdirs for each SMT thread on SMT systems. I agree with Peter and Morten. "cpu" is more clear and consistent than "thread" here. I'll spin the series with that string changed. > > Another thing that I find confusing is that with this series we a new > > die id/mask which is totally unrelated to the DIE level in the > > sched_domain hierarchy. We should rename DIE level to something that > > reflects what it really is. If we can agree on that ;-) > > > > NODE level? Cache topology and node interconnect topology impact performance, and so we what we look at, when we decided to run something on this CPU or that one. That logical topology lives within the physical package and die topology, but doesn't necessarily match it. For example, caches can be shared or split into pieces inside a package or die. Logical nodes may match die boundaries, or there may be multiple logical nodes within a single physical package or die. We have mechanisms for explicitly enumerating the caches, and for nodes. This patch series does not touch those mechanisms. The reason we need to know about physical packages and die is that there are other things associated with them. eg. power and temperature domains, and certain system registers follow these physical boundaries. Code that talks to those items needs to be able to understand these physical boundaries. I hope that helps. thanks, Len Brown, Intel Open Source Technology Center
Powered by blists - more mailing lists