Re: [PATCH v2 RESEND] xfstests generic/320: heavy rm workload test

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

 



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@xxxxxxxxxxxxx

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs




[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux