[PATCH v2 RESEND] xfstests generic/320: heavy rm workload test
Dave Chinner
david at fromorbit.com
Mon Nov 11 23:02:50 CST 2013
On Tue, Nov 12, 2013 at 12:18:10PM +0800, Eryu Guan wrote:
> This test is based on generic/273, a regression test for commit
>
> 9a3a5da xfs: check for stale inode before acquiring iflock on push
>
> On unpatched kernel, rm processes would hang.
....
> +threads=50
> +count=2
> +fs_size=$((2 * 1024 * 1024 * 1024))
> +ORIGIN=$SCRATCH_MNT/origin
> +
> +threads_set()
> +{
> + cpu_num=`grep -c processor /proc/cpuinfo`
Please us src/feature for this. See commit:
2dcf4a5 xfstests: src/feature.c: print a number of online CPUs
> + threads=$(($cpu_num * 50))
> + if [ $threads -gt 200 ]
> + then
> + threads=200
> + fi
> +}
Didn't we go through this before? Or was that the review that lead
to the above commit? i.e. to use $LOAD_FACTOR to scale the workload,
not the number of CPUs....
> +
> +file_create()
> +{
> + i=0
> + mkdir $ORIGIN
> +
> + disksize=$(($fs_size / 3))
> + num=$(($disksize / $count / $threads / 4096))
> + while [ $i -lt $num ]; do
> + $XFS_IO_PROG -f -c "pwrite 0 $((4096*count))" $ORIGIN/file_$i >>$seqres.full 2>&1
Line too long.
Cheers,
Dave.
--
Dave Chinner
david at fromorbit.com
More information about the xfs
mailing list