Date: Wed, 11 Oct 2000 21:07:42 -0700 From: Jason Evans <jasone@canonware.com> To: Jun Kuriyama <kuriyama@imgsrc.co.jp> Cc: current@FreeBSD.ORG Subject: Re: -current grinds exceeding slow Message-ID: <20001011210742.B11949@canonware.com> In-Reply-To: <7mn1gaenfa.wl@waterblue.imgsrc.co.jp>; from kuriyama@imgsrc.co.jp on Thu, Oct 12, 2000 at 12:41:29PM %2B0900 References: <l03130312b60886cc585c@[194.32.164.2]> <XFMail.001011114214.jhb@FreeBSD.org> <7mn1gaenfa.wl@waterblue.imgsrc.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 12, 2000 at 12:41:29PM +0900, Jun Kuriyama wrote: > At 11 Oct 2000 18:43:14 GMT, > John Baldwin <jhb@FreeBSD.ORG> wrote: > > I don't know. Can you try to narrow down the date by cvsupping or > > cvs updating with date tags to see when it started slowing down? > > I've checked with -D '2000-10-03 00:00:00 GMT' and -D '2000-10-04 > 12:00:00 GMT'. With previous kernel, "time find /usr/obj" returns 65 > seconds, but with later kernel, it returns 547 seconds (/usr/obj is > NFS mounted from localhost). > > Top command shows many processes locked with MUTEX status. It seems > this is caused by jasone's commit at 3rd Oct... Do you have the SMP_DEBUG kernel option enabled? My changes added lots of mutexes to the kernel, and mtx_validate() iterates through all mutexes for mtx_init() and mtx_destroy() calls if SMP_DEBUG is enabled. I'm working on a change that will use a pool of mutexes that are allocated at boot time, which will make this slow down go away, but it may be a while before it gets checked in. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001011210742.B11949>