Date: Mon, 5 Feb 1996 15:26:18 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, gibbs@freefall.freebsd.org Cc: curt@emergent.com, freebsd-hackers@freebsd.org, jgreco@brasil.moneng.mei.com Subject: Re: Watchdog timers (was: Re: Multi-Port Async Cards) Message-ID: <199602050426.PAA27801@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>I thought -current would be much better with -o async. However: >> >>FreeBSD-current - 486DX2/66 - 16MB RAM (BT445C Quantum Grand Prix drive, >>1/3 full 1G fs) >>(too-small buffer cache (nbuf = 247) + vm buffers that I don't understand) >> >>10000 files in 468 seconds - first run >> 467.76 real 0.87 user 17.19 sys (time /tmp/prog) >> 0.33 real 0.01 user 0.03 sys (time sync) >>10000 files in 295 seconds - second run >> 295.34 real 0.87 user 12.86 sys (time /tmp/prog) >> 0.33 real 0.02 user 0.02 sys (time sync) >Yes, but this is not exactly fair. Your SCSI controller only has 5 times >the command overhead as your IDE card (because you have a very poor SCSI >controller). [The Minix-1.6.25++ - 486DX/33 - 8MB RAM (slow IDE controller, slow IDE drive, fresh 137MB fs) are about 17 seconds for the first run and 12 seconds for the second run.] Should I upgrade to a ST01 controller? ;-) The controller overhead was almost irrelevant for the Minix-IDE setup because the disk activity LED only blinked on for a second or two out of the 17 seconds. For FreeBSD the disk LED was on for about 468 seconds out of 468. Joe's time of "only" a couple of hundred seconds for the first run may be due to lower command overhead. >I'd like to see the performance difference on the same >hardware. FreeBSD-current - 486DX/33 - 8MB RAM (slow IDE controller, slow IDE drive, fresh 137MB fs in same partition as for Minix): -o async: 10000 files in 662 seconds - first run 662.13 real 1.60 user 24.56 sys 0.56 real 0.01 user 0.05 sys 10000 files in 407 seconds - second run 406.91 real 1.38 user 17.39 sys 0.26 real 0.01 user 0.03 sys $ time find . >/dev/null 18.07 real 0.86 user 1.81 sys $ time find . >/dev/null 19.62 real 0.87 user 1.85 sys $ time du >/dev/null 39.35 real 1.22 user 6.50 sys $ time du >/dev/null 38.16 real 1.11 user 6.48 sys $ time rm -rf * 45.27 real 0.81 user 10.41 sys sync: 10000 files in 939 seconds - first run 939.37 real 1.50 user 33.07 sys 0.39 real 0.02 user 0.03 sys `find .' and `du': similar to above. $ time rm -rf * 256.36 real 0.93 user 16.43 sys It's surprising how many sync writes there are for async mounted file systems. I zapped the one that seemed to be the most common: --- *** /sys/ufs/ufs/ufs_readwrite.c~ Sat Jan 20 06:57:41 1996 --- /sys/ufs/ufs/ufs_readwrite.c Mon Feb 5 14:10:03 1996 *************** *** 284,288 **** if (ioflag & IO_SYNC) { ! (void)bwrite(bp); } else if (xfersize + blkoffset == fs->fs_bsize) { if (doclusterwrite) { --- 287,295 ---- if (ioflag & IO_SYNC) { ! if (vp->v_mount->mnt_flag & MNT_ASYNC) ! bdwrite(bp); ! else ! (void)bwrite(bp); ! /* XXX write-through when the block fills up is sloooow. */ } else if (xfersize + blkoffset == fs->fs_bsize) { if (doclusterwrite) { --- but this only improved the time from 662 seconds to 633 seconds. Don't try this change if you value your async mounted file systems - it's too late to check the MNT_ASYNC flag here since i/o to async-mounted file systems must be synchronous for at least the fsync() system call. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602050426.PAA27801>