cvs commit: src/sys/vm vm_map.c vm_map.h
jhb at FreeBSD.org
Tue Aug 3 10:00:44 PDT 2004
On Monday 02 August 2004 10:58 pm, Stephan Uphoff wrote:
> 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).
Good catch! Unfortunately, the problems I was seeing above involved locks
that didn't use upgrade or downgrade. :( I've pondered taking an axe to all
of lockmgr and just rewriting it from scratch to use mutexes and cv's like
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the cvs-all