Feature request: fractional threads-required

[JesseTheRobot]

Motivation

I use nextest on a fairly sized project, and use threads-required to prevent resource contention issues in CI & locally.
The current integer nature of threads-required means that I cannot precisely right size the values for tests - some consume 0.5 threads worth of compute on average, while some consume 3.5. This is not a major detriment but I am looking to improve resource utilisation to speed up test execution.

Proposal

Change threads-required to support fractional values (i.e 0.5, 3.5) - probably with a reasonable precision limit (1 decimal place)

Alternatives

None so far

Additional context

This is partially a probe to get an idea of sentiment and whether such a feature would be accepted, as I am willing to work on implementing this myself. If anyone can see a reason for allowing more than 1DP of precision here let me know.

[sunshowers]

Thanks for the feature request. I don't know how I feel about this -- it seems somewhat niche to me. Out of curiosity have you seen if this makes an actual performance difference?

[JesseTheRobot]

This is definitely rather niche yes - unfortunately I cannot say on the performance increase, but given that most of our tests are CPU bound the extra ~10-20% left over should map to a pretty even 10-20% performance increase

[JesseTheRobot]

As a side note - have you ever thought about supporting more resource classes? currently you can tell nextest that a test requires N CPUs, but what about, for example, telling it a test needs X IOPS (out of some number of IOPS you can pass through as available via a config). You could probably make this generic over any resource type (test requires N of something, you tell nextest there's a pool of X something available to it)

[sunshowers]

Yes, it's something I've given a bit of thought to (particularly for machines with high core count + low RAM), but multidimensional scheduling and rate limiting quickly spirals out of complexity. (For example, 1D bin packing is pretty simple, while 2D+ bin packing is NP-hard.)

Kubernetes has multi-dimensional scheduling across CPU and memory I believe, and it gets quite complex very quickly.

One idea might be to configure and use profiles for different scenarios. For example, have a profile with a different set of per-test overrides for high core count/low RAM cases.