Is there a plan to move away from arch dependent cpuinfo file to lscup
when creating an affinity map? It has clearly different a format on AArch64.
I’m not sure lscpu program is any better and it’s not standard on Linux the way /proc/cpuinfo is.
What is the specific problem you are seeing? Perhaps you can explain that before trying to design a solution.
Jeff
Jeff,
Linux supports other arches than X86, and the
layout of cpuinfo is different across the architectures.
In the runtime code if you take a look at already there are ifdefs.
Itaru.
Jeff,
Linux supports other arches than X86, and the
layout of cpuinfo is different across the architectures.In the runtime code if you take a look at already there are ifdefs.
Itaru.
The alternative that you're proposing is to fork lscpu to read /proc/cpuinfo instead?
We do understand that /proc/cpuinfo has architecture dependencies, and this is unfortunate in this context, but it is the interface that Linux provides. How does lscpu deal with those dependencies? Should our parser just be more robust?
-Hal
I still haven’t seen a problem statement from the original poster, but it seems like hwloc is the solution if maintaining architecture-specific porting of /proc/cpuinfo is too difficult. However, this should be demonstrated with a bug report and unsupported use case before alternatives are discussed.
Jeff
Linux supports other arches than X86,
I know - I’ve Linux on at least half a dozen architectures, from Itanium to POWER9.
LLVM supports other operating systems besides Linux, so it must not be fully reliant on /proc/cpuinfo anyways, and lscpu doesn’t increase portability because it too is Linux-specific. While it might appear to solve a problem, the OpenMP is still going to be dependent on the stability of that output format across architectures and through time.
and the layout of cpuinfo is different across the architectures.
The whole point of a runtime library like KMP is to deal with architectural support, so it seems entirely within its scope to deal with /proc/cpuinfo layout variation. I do not know why you think this is a problem and want to solve the problem by making KMP dependent on another Linux-specific thing.
In the runtime code if you take a look at already there are ifdefs.
Yes, and I see that hwloc is already supported, which suggests that the OpenMP runtime can support any platform that hwloc does, which is quite a bit more than Linux or x86.
#if KMP_USE_HWLOC
case affinity_top_method_hwloc:
value = “hwloc”;
break;
#endif
Jeff
The cpuinfo file topology method was designed to show the library machine topology without requiring it to investigate the topology itself.
The file can be written manually, it should not necessarily be /proc/cpuinfo. It can be /my_folder/my_cpuinfo_file for example, or c:\my_folder\my_cpuinfo_file.txt on Windows.
Only requirement is to follow format that the library can recognize. One can always write own file, e.g. basing on info provided by lscpu or any other tool.
This method can work on any architecture that allows to bind a thread using an affinity mask.
The goal was to allow to test affinity on machines where cpuid instruction cannot work, or cpuid has interface that the library cannot recognize, or to test binding on some future architecture using old system, or to avoid issuing cupid instruction by the library for some reason, etc.
– Andrey
I think on Linux, hardware info is supposed to
obtained through sysfs, in an architecture independent way. But as Jeff says the consensus is that we don’t touch the code until bugs pop up, that’s fine.