Date: Thu, 12 Oct 2000 15:45:02 -0700 From: Jason Evans <jasone@canonware.com> To: Jason Evans <jasone@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf param.c src/sys/kern kern_lock.c src/sys/sys kernel.h lock.h src/sys/vm vm_map.h Message-ID: <20001012154502.E11949@canonware.com> In-Reply-To: <200010122237.PAA12428@freefall.freebsd.org>; from jasone@FreeBSD.org on Thu, Oct 12, 2000 at 03:37:29PM -0700 References: <200010122237.PAA12428@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 12, 2000 at 03:37:29PM -0700, Jason Evans wrote: > Modified files: > sys/conf param.c > sys/kern kern_lock.c > sys/sys kernel.h lock.h > sys/vm vm_map.h > Log: > For lockmgr mutex protection, use an array of mutexes that are allocated > and initialized during boot. This avoids bloating sizeof(struct lock). > As a side effect, it is no longer necessary to enforce the assumtion that > lockinit()/lockdestroy() calls are paired, so the LK_VALID flag has been > removed. A number of people have complained about a major performance drop starting with the commit of my initial lockmgr changes on ~3 October. Those changes caused many mutexes to be added to the system, with lots of calls to mtx_init()/mtx_destroy(), which then call mtx_validate() if the SMP_DEBUG option is enabled. mtx_validate() iterates through all the mutexes to look for problems, so things were very slow. This latest commit drastically reduces the number of mutexes (from potentially thousands down to 11), and lockinit()/lockdestroy() no longer cause mtx_init()/mtx_destroy() to be called, so the slowdown should go away. Jason 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?20001012154502.E11949>