On Thu, 20 Feb 2025 at 16:48, Dev Jain <dev.jain@xxxxxxx> 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.
