On Tue, Jan 21, 2025 at 02:58:25PM +1100, Dave Chinner wrote:
> > +# Are there mkfs options to try to improve concurrency?
> > +_scratch_mkfs_concurrency_options()
> > +{
> > + local nr_cpus="$(( $1 * LOAD_FACTOR ))"
>
> caller does not need to pass a number of CPUs. This function can
> simply do:
>
> local nr_cpus=$(getconf _NPROCESSORS_CONF)
>
> And that will set concurrency to be "optimal" for the number of CPUs
> in the machine the test is going to run on. That way tests don't
> need to hard code some number that is going to be too large for
> small systems and to small for large systems...
Hmm, but is this the right thing if you are using check-parallel? If
you are running multiple tests that are all running some kind of load
or stress-testing antagonist at the same time, then having 3x to 5x
the number of necessary antagonist threads is going to unnecessarily
slow down the test run, which goes against the original goal of what
we were hoping to achieve with check-parallel.
How many tests are you currently able to run in parallel today, and
what's the ultimate goal? We could have some kind of antagonist load
which is shared across multiple tests, but it's not clear to me that
it's worth the complexity. (And note that it's not just fs and cpu
load antagonistsw; there could also be memory stress antagonists, where
having multiple antagonists could lead to OOM kills...)
- Ted
