cvs commit: src/sys/vm vm_fault.c
Alan Cox
alc at cs.rice.edu
Sat Aug 21 17:16:03 PDT 2004
On Sat, Aug 21, 2004 at 07:41:16PM -0400, Brian Fundakowski Feldman wrote:
> On Sat, Aug 21, 2004 at 06:31:34PM -0500, Alan Cox wrote:
> > On Sat, Aug 21, 2004 at 06:59:39PM -0400, Brian Fundakowski Feldman wrote:
> > > On Sat, Aug 21, 2004 at 07:20:21PM +0000, Alan Cox wrote:
> > > > alc 2004-08-21 19:20:21 UTC
> > > >
> > > > FreeBSD src repository
> > > >
> > > > Modified files:
> > > > sys/vm vm_fault.c
> > > > Log:
> > > > Further reduce the use of Giant by vm_fault(): Giant is held only when
> > > > manipulating a vnode, e.g., calling vput(). This reduces contention for
> > > > Giant during many copy-on-write faults, resulting in some additional
> > > > speedup on SMPs.
> > > >
> > > > Note: debug_mpsafevm must be enabled for this optimization to take effect.
> > >
> > > This is very broken. See included first attempt at fixing it without
> > > regard for actually trying to reimplement debug.mpsafenet for vnodes.
> > >
> >
> > Can you please explain what is broken?
>
> #1. Lock order reversal. Giant is acquired after the map read lock.
No, that is the order it has been in for months. The other functions
that acquire a map lock and Giant do the same.
> #2. Unlocking Giant without it being locked. This occurs in both
> VM_UNLOCK_GIANT() lines I removed. I know this because my machine
> panicked on the other after I removed the first.
Yes, I see what happened. I was able to reproduce it. As the commit
explains, I failed to condition an early unlock of Giant on debug_mpsafevm.
Regards,
Alan
More information about the cvs-src
mailing list