Date: Mon, 02 Aug 2004 22:58:10 -0400 From: Stephan Uphoff <ups@tree.com> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_map.c vm_map.h Message-ID: <200408030258.i732wAfY098990@palm.tree.com> In-Reply-To: Message from John Baldwin <jhb@FreeBSD.org> of "Fri, 30 Jul 2004 15:32:24 EDT." <200407301532.24968.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Friday 30 July 2004 12:06 pm, Brian Fundakowski Feldman wrote: > > On Fri, Jul 30, 2004 at 09:10:28AM +0000, Maxime Henrion wrote: > > > mux 2004-07-30 09:10:28 UTC > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/vm vm_map.c vm_map.h > > > Log: > > > Get rid of another lockmgr(9) consumer by using sx locks for the user > > > maps. We always acquire the sx lock exclusively here, but we can't > > > use a mutex because we want to be able to sleep while holding the > > > lock. This is completely equivalent to what we were doing with the > > > lockmgr(9) locks before. > > > > Not that I don't think it's worth doing in general, but is there a > > comparison anyone has done between speeds of sx and lockmgr? > > Speed aside, when allproc_lock and proctree_lock were lockmgr locks (before sx > was implemented), my SMP machines routinely locked up and when I looked at > things in the debugger it seemed that no one held allproc_lock but several > processes were blocked on it. Quite frankly, I don't trust lockmgr()'s > implementation. > Since the vfs layer forces me to use the lockmgr you scared me into taking a look. And yes there is a bug in the current implementation. (kern/69934). Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408030258.i732wAfY098990>