On Thu, Jan 16, 2025 at 03:28:33PM -0800, Darrick J. Wong wrote: > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > Prior to commit 8973af00ec21, in the absence of an explicit > SOAK_DURATION, this test would run 2500 fsstress operations each of ten > times through the loop body. On the author's machines, this kept the > runtime to about 30s total. Oddly, this was changed to 30s per loop > body with no specific justification in the middle of an fsstress process > management change. I'm pretty sure that was because when you run g/650 on a machine with 64p, the number of ops performed on the filesystem is nr_cpus * 2500 * nr_loops. In that case, each loop was taking over 90s to run, so the overall runtime was up in the 15-20 minute mark. I wanted to cap the runtime of each loop to min(nr_ops, SOAK_DURATION) so that it ran in about 5 minutes in the worst case i.e. (nr_loops * SOAK_DURATION). I probably misunderstood how -n nr_ops vs --duration=30 interact; I expected it to run until either were exhausted, not for duration to override nr_ops as implied by this: > On the author's machine, this explodes the runtime from ~30s to 420s. > Put things back the way they were. Yeah, OK, that's exactly waht keep_running() does - duration overrides nr_ops. Ok, so keeping or reverting the change will simply make different people unhappy because of the excessive runtime the test has at either ends of the CPU count spectrum - what's the best way to go about providing the desired min(nr_ops, max loop time) behaviour? Do we simply cap the maximum process count to keep the number of ops down to something reasonable (e.g. 16), or something else? -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
