Date: Thu, 14 Dec 2006 02:41:33 -0500 From: Kris Kennaway <kris@obsecurity.org> To: Dieter <freebsd@sopwith.solgatos.com> Cc: freebsd-questions@freebsd.org Subject: Re: processes not getting fair share of available disk I/O Message-ID: <20061214074133.GA67465@xor.obsecurity.org> In-Reply-To: <200612140642.GAA11733@sopwith.solgatos.com> References: <20061214012035.GA62554@xor.obsecurity.org> <200612140642.GAA11733@sopwith.solgatos.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 13, 2006 at 10:42:03PM +0000, Dieter wrote: > > Mutex profiling would show if there is a mutex somehow getting in the > > way of your I/O (e.g. if Giant is somehow being forced). I dont think > > it would show anything though. You can try to study interrupt issues > > (e.g. look for an interrupt storm during I/O) with vmstat -i. Other > > than that you'd probably have to get your hands dirtier in the code. >=20 > max total count avg cnt_hold cnt_lock name > 1158725 1185330 1596 742 0 0 /usr/src= /sys/amd64/amd64/pmap.c:1563 (pmap) > 1158721 1166593 1596 730 1 17 /usr/src= /sys/amd64/amd64/pmap.c:1562 (vm page queue mutex) > 90598 578551 199304 2 3 4 /usr/src/= sys/kern/kern_sx.c:157 (lockbuilder mtxpool) > 83234 967612 124000 7 0 0 /usr/src/= sys/vm/vm_fault.c:906 (vm object) > 83102 2515439 450378 5 0 0 /usr/src/= sys/kern/subr_sleepqueue.c:369 (process lock) > 82878 2049540 3215 637 196 2 /usr/src/= sys/kern/kern_synch.c:236 (Giant) > 82632 947545 124000 7 0 4 /usr/src/= sys/vm/vm_fault.c:295 (vm object) > 82550 285981 124000 2 4 0 /usr/src/= sys/vm/vm_fault.c:929 (process lock) > 46745 46789 11 4253 0 0 /usr/src/= sys/kern/vfs_subr.c:1041 (vm object) > 46741 52927 646 81 1 0 /usr/src/= sys/vm/vm_object.c:1775 (vm page queue mutex) > 30068 105046 1230 85 2 0 /usr/src/= sys/vm/vm_map.c:1380 (vm object) > 24083 300793 136380 2 1 1 /usr/src/= sys/vm/vm_object.c:454 (vm object) > 24076 32222 2960 10 2 0 /usr/src/= sys/vm/vm_object.c:625 (vm page queue mutex) > 19419 70113 7295 9 0 0 /usr/src/= sys/vm/vm_fault.c:787 (vm object) > 16024 65388 5494 11 1 2 /usr/src/= sys/vm/vnode_pager.c:1181 (vnode interlock) > 16018 51608 8791 5 7 9 /usr/src/= sys/vm/vnode_pager.c:1169 (vm object) > 14398 1084811 25198 43 108 3 /usr/src/= sys/kern/kern_sysctl.c:1280 (Giant) > 11940 274443 37582 7 0 1 /usr/src/= sys/kern/vfs_bio.c:3082 (vm object) > 11567 625811 312742 2 0 2 /usr/src/= sys/kern/kern_lock.c:168 (lockbuilder mtxpool) > 11096 45666 5241 8 1 4 /usr/src/= sys/vm/vm_map.c:2404 (vm object) >=20 >=20 > If I'm reading the man page right, pmap holds a lock for over 1 second? In total, over 1600 operations. It's not an issue. The rest looks fine at a quick glance too. Kris --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFgQAtWry0BWjoQKURApjDAJsEwjZrIm4pIgG60Ir5G469KvI3fACgooAw yUAN8Dh8PB1U14s9VqgHwfo= =oIo4 -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061214074133.GA67465>