From owner-cvs-all  Tue Oct 16  9:53:40 2001
Delivered-To: cvs-all@freebsd.org
Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31])
	by hub.freebsd.org (Postfix) with ESMTP
	id CCE3037B40E; Tue, 16 Oct 2001 09:53:33 -0700 (PDT)
Received: by flood.ping.uio.no (Postfix, from userid 2602)
	id 4D59614C2E; Tue, 16 Oct 2001 18:53:31 +0200 (CEST)
X-URL: http://www.ofug.org/~des/
X-Disclaimer: The views expressed in this message do not necessarily
  coincide with those of any organisation or company with
  which I am or have been affiliated.
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
References: <200110161629.f9GGTju31481@apollo.backplane.com>
	<xzpr8s3wnee.fsf@flood.ping.uio.no>
From: Dag-Erling Smorgrav <des@ofug.org>
Date: 16 Oct 2001 18:53:30 +0200
In-Reply-To: <xzpr8s3wnee.fsf@flood.ping.uio.no>
Message-ID: <xzpn12rwmph.fsf@flood.ping.uio.no>
Lines: 22
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG

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