Re: [PATCH 13/23] generic/650: revert SOAK DURATION changes

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On Tue, Jan 21, 2025 at 03:57:23PM +1100, Dave Chinner wrote:
> 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.

Where does that happen?

Oh, heh.  -n is the number of ops *per process*.

> 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:

Yeah, SOAK_DURATION overrides pretty much everything.

> > 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?

How about running fsstress with --duration=3 if SOAK_DURATION isn't set?
That should keep the runtime to 30 seconds or so even on larger
machines:

if [ -n "$SOAK_DURATION" ]; then
	test "$SOAK_DURATION" -lt 10 && SOAK_DURATION=10
	fsstress_args+=(--duration="$((SOAK_DURATION / 10))")
else
	# run for 3s per iteration max for a default runtime of ~30s.
	fsstress_args+=(--duration=3)
fi

--D

> -Dave.
> -- 
> Dave Chinner
> david@xxxxxxxxxxxxx
> 




[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux