On Thu, 20 Feb 2025 at 16:48, Dev Jain dev.jain@arm.com wrote:
On 20/02/25 8:33 pm, Brendan Jackman wrote:
This calculation divides a fixed parameter by an environment-dependent parameter i.e. the number of CPUs.
The simple way to avoid machine-specific failures here is to just put a cap on the max value of the latter.
I haven't read the test, but if nr_cpus is being computed, then this value must be important to the test somehow? Would it potentially be wrong to let the test run for nr_cpus != actual number of cpus?
Based on my _extremely hasty_ reading, the variable is misnamed and it's actually a thread count not a CPU count. I can double check that's the case and rename it.
Also, if the patch is correct then will it be better to also print a diagnostic telling the user that the number of cpus is going to be capped for the test to run?
Sure. The level of detail in the logging and error messages is extremely low here so I didn't feel like being too anomalous, but why not.