From owner-cvs-all  Tue Oct 16 10:34:54 2001
Delivered-To: cvs-all@freebsd.org
Received: from femail2.sdc1.sfba.home.com (femail2.sdc1.sfba.home.com [24.0.95.82])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3EA4037B440; Tue, 16 Oct 2001 10:34:34 -0700 (PDT)
Received: from laptop.baldwin.cx ([24.2.39.156])
          by femail2.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP
          id <20011016173434.CWDX11144.femail2.sdc1.sfba.home.com@laptop.baldwin.cx>;
          Tue, 16 Oct 2001 10:34:34 -0700
Message-ID: <XFMail.011016103432.jhb@FreeBSD.org>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <xzpn12rwmph.fsf@flood.ping.uio.no>
Date: Tue, 16 Oct 2001 10:34:32 -0700 (PDT)
From: John Baldwin <jhb@FreeBSD.org>
To: Dag-Erling Smorgrav <des@ofug.org>
Subject: Re: cvs commit: src/sys/vm vnode_pager.c
Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG,
	Bruce Evans <bde@zeta.org.au>,
	Matthew Dillon <dillon@apollo.backplane.com>
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


On 16-Oct-01 Dag-Erling Smorgrav wrote:
> 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.

How about turning off INVARIANTS and WITNESS and seeing if it does better?
Witness did become more expensive when I made it work for reader/writer locks
on May 4 as it has to manage a list of lock instances instead of embedding the
list inside the lock object itself. 

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message