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.
Hardware concurrency
It isn't entirely clear how physical cores, logical cores and per core hardware threads map to NUMBER_OF_PHYSICAL_CORES
and NUMBER_OF_LOGICAL_CORES
.
-
On a Sparc system with 1 physical core, 8 logical cores and 8 per core threads
NUMBER_OF_LOGICAL_CORES
was reported with 0 @DerDakon suggested the exact layout is not visible in/proc/cpuinfo
but I am unsure if the list includes 8 or 64 entries. -
I think we probably want
NUMBER_OF_LOGICAL_CORES
to reflect hardware threads (I think that is what e.g. Intel / AMD Linux HT Systems report via/proc/cpuinfo
) -
We might want to use
std::thread::hardware_concurrency()
(after verification) as the default forNUMBER_OF_LOGICAL_CORES
-
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_CORES
to be the total number of hardware threads (not per CPU)
Memory
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 *_VIRTUAL_MEMORY
is 0
.
- 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
- Should
AVAILABLE_VIRTUAL_MEMORY
/AVAILABLE_PHYSICAL_MEMORY
be 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.