From: "Darrick J. Wong" <djwong@kernel.org>
To: riteshh <riteshh@linux.ibm.com>
Cc: guaneryu@gmail.com, linux-xfs@vger.kernel.org,
fstests@vger.kernel.org, guan@eryu.me
Subject: Re: [PATCH 1/1] generic: fsstress with cpu offlining
Date: Fri, 17 Sep 2021 16:48:17 -0700 [thread overview]
Message-ID: <20210917234817.GA10197@magnolia> (raw)
In-Reply-To: <20210917183449.wyvvy436j3ifeazx@riteshh-domain>
On Sat, Sep 18, 2021 at 12:04:49AM +0530, riteshh wrote:
> On 21/09/15 04:42PM, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> >
> > Exercise filesystem operations when we're taking CPUs online and offline
> > throughout the test.
>
> Nice test coverage. Btw, I may have missed older versions, but could you point
> to the link which points to the bugs which this test uncovered?
> I guess it will be good to add tha in the comment section of test description
> too.
I didn't uncover any bugs with 5.14, fortunately. Dave Chinner was
messing around with per-CPU lists in XFS, so I figured I had better
write something to exercise the cpu-dead handlers to try to make sure
there weren't any obvious bugs in the code, and this is the result.
> This also made me think whether doing memory online/offline while
> running
> fsstress, makes any sense?
Heh, perhaps. I hadn't gotten /that/ far... :)
--D
>
> >
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> > tests/generic/726 | 74 +++++++++++++++++++++++++++++++++++++++++++++++++
> > tests/generic/726.out | 2 +
> > 2 files changed, 76 insertions(+)
> > create mode 100755 tests/generic/726
> > create mode 100644 tests/generic/726.out
> >
> >
> > diff --git a/tests/generic/726 b/tests/generic/726
> > new file mode 100755
> > index 00000000..1a3f2fad
> > --- /dev/null
> > +++ b/tests/generic/726
> > @@ -0,0 +1,74 @@
> > +#! /bin/bash
> > +# SPDX-License-Identifier: GPL-2.0
> > +# Copyright (c) 2021 Oracle, Inc. All Rights Reserved.
> > +#
> > +# FS QA Test No. 726
> > +#
> > +# Run an all-writes fsstress run with multiple threads while exercising CPU
> > +# hotplugging to shake out bugs in the write path.
> > +#
> > +. ./common/preamble
> > +_begin_fstest auto rw stress
>
> Does it qualify for auto? This definitely is taking a longer time compared to
> other auto tests on my qemu setup.
>
> > +
> > +# Override the default cleanup function.
> > +_cleanup()
> > +{
> > + cd /
> > + rm -f $tmp.*
> > + $KILLALL_PROG -9 fsstress > /dev/null 2>&1
> > + wait # for exercise_cpu_hotplug subprocess
> > + for i in "$sysfs_cpu_dir/"cpu*/online; do
> > + echo 1 > "$i" 2>/dev/null
> > + done
> > + test -n "$stress_dir" && rm -r -f "$stress_dir"
> > +}
> > +
> > +exercise_cpu_hotplug()
> > +{
> > + while [ -e $sentinel_file ]; do
> > + local idx=$(( RANDOM % nr_hotplug_cpus ))
> > + local cpu="${hotplug_cpus[idx]}"
> > + local action=$(( RANDOM % 2 ))
> > +
> > + echo "$action" > "$sysfs_cpu_dir/cpu$cpu/online" 2>/dev/null
> > + sleep 0.5
> > + done
> > +}
> > +
> > +_supported_fs generic
> > +_require_test
> > +_require_command "$KILLALL_PROG" "killall"
> > +
> > +sysfs_cpu_dir="/sys/devices/system/cpu"
> > +
> > +# Figure out which CPU(s) support hotplug.
> > +nrcpus=$(getconf _NPROCESSORS_CONF)
> > +hotplug_cpus=()
> > +for ((i = 0; i < nrcpus; i++ )); do
> > + test -e "$sysfs_cpu_dir/cpu$i/online" && hotplug_cpus+=("$i")
> > +done
> > +nr_hotplug_cpus="${#hotplug_cpus[@]}"
> > +test "$nr_hotplug_cpus" -gt 0 || _notrun "CPU hotplugging not supported"
> > +
> > +stress_dir="$TEST_DIR/$seq"
> > +rm -r -f "$stress_dir"
> > +mkdir -p "$stress_dir"
> > +
> > +echo "Silence is golden."
> > +
> > +sentinel_file=$tmp.hotplug
> > +touch $sentinel_file
> > +exercise_cpu_hotplug &
> > +
> > +# Cap the number of fsstress threads at one per hotpluggable CPU if we exceed
> > +# 1024 IO threads, per maintainer request.
> > +nr_cpus=$((LOAD_FACTOR * nr_hotplug_cpus))
> > +test "$nr_cpus" -gt 1024 && nr_cpus="$nr_hotplug_cpus"
> > +
> > +nr_ops=$((25000 * TIME_FACTOR))
> > +$FSSTRESS_PROG $FSSTRESS_AVOID -w -d $stress_dir -n $nr_ops -p $nr_cpus >> $seqres.full
> > +rm -f $sentinel_file
> > +
> > +# success, all done
> > +status=0
> > +exit
> > diff --git a/tests/generic/726.out b/tests/generic/726.out
> > new file mode 100644
> > index 00000000..6839f8ce
> > --- /dev/null
> > +++ b/tests/generic/726.out
> > @@ -0,0 +1,2 @@
> > +QA output created by 726
> > +Silence is golden.
> >
prev parent reply other threads:[~2021-09-17 23:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-15 23:42 [PATCHSET v3 0/1] fstests: exercise code refactored in 5.14 Darrick J. Wong
2021-09-15 23:42 ` [PATCH 1/1] generic: fsstress with cpu offlining Darrick J. Wong
2021-09-17 18:34 ` riteshh
2021-09-17 23:48 ` Darrick J. Wong [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210917234817.GA10197@magnolia \
--to=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=guan@eryu.me \
--cc=guaneryu@gmail.com \
--cc=linux-xfs@vger.kernel.org \
--cc=riteshh@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox