Date: 16 Oct 2001 18:53:30 +0200 From: Dag-Erling Smorgrav <des@ofug.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Bruce Evans <bde@zeta.org.au>, <cvs-committers@FreeBSD.ORG>, <cvs-all@FreeBSD.ORG> Subject: Re: cvs commit: src/sys/vm vnode_pager.c Message-ID: <xzpn12rwmph.fsf@flood.ping.uio.no> In-Reply-To: <xzpr8s3wnee.fsf@flood.ping.uio.no> References: <200110161629.f9GGTju31481@apollo.backplane.com> <xzpr8s3wnee.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav <des@ofug.org> writes: > Matthew Dillon <dillon@apollo.backplane.com> writes: > > ffs_sync() in -current is doing a lot of mutex operations > > in the loop. If you have various -current mutex debugging > > options turned on, even the default ones I think, this could > > be responsible for the latency you are experiencing. Each > > scan loop is doing four mutex ops. > So, what changed in the witness code to make it so slow (or in the FFS > code to make it perform so many mutex operations) around late June / > early July? BTW, the profiling data show that mutex debugging actually have very little impact - 88% of CPU time is spent in _mtx_unlock_spin_flags(), and only 0.6% in witness_unlock() (which _mtx_unlock_spin_flags() calls). Witness functions amount to about 3% all told, _mtx_assert() accounts for 0.1%. The problem isn't mutex debugging, or mutex handling at all - the problem is that ffs_fsync() has an insane amount of work to do, most of which is probably bogus. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpn12rwmph.fsf>