cmake_host_system_information: Potential ambiguities and inconsistencies
In !6014 (merged) some potential issues with
cmake_host_system_information() and underlying KWSYS implementation were found.
It isn't entirely clear how physical cores, logical cores and per core hardware threads map to
On a Sparc system with 1 physical core, 8 logical cores and 8 per core threads
NUMBER_OF_LOGICAL_CORESwas reported with 0 @DerDakon suggested the exact layout is not visible in
/proc/cpuinfobut I am unsure if the list includes 8 or 64 entries.
I think we probably want
NUMBER_OF_LOGICAL_CORESto reflect hardware threads (I think that is what e.g. Intel / AMD Linux HT Systems report via
We might want to use
std::thread::hardware_concurrency()(after verification) as the default for
CMake test should probably fail when
NUMBER_OF_PHYSICAL_CORES/NUMBER_OF_LOGICAL_CORES < 1
The documentation should clarify that we intend
NUMBER_OF_LOGICAL_CORESto be the total number of hardware threads (not per CPU)
TOTAL_VIRTUAL_MEMORY / AVAILABLE_VIRTUAL_MEMORY reflects swap on Linux systems while it reflects virtual memory (swap + physical) on Windows. On Linux systems with no swap
- The implementations should be made consistent. Virtual memory should include physical memory. Swap memory should perhaps be reported separately
- The documentation should clarify what is meant specifically; platform specifics if we can not get consistent information
AVAILABLE_PHYSICAL_MEMORYbe bound by per process user space limits or should we perhaps report those additionally (e.g. size of user address space and / or OS limits set on a process)? I think there might be use cases for either. E.g. creating a heuristic to determine the number of compression threads running in a single process and e.g. creating a heuristic for a number of compile jobs to spawn where each compiler invocation runs in its own process.