Date: Sat, 26 May 2001 02:42:20 -0700 From: Peter Wemm <peter@wemm.org> To: Alfred Perlstein <alfred@FreeBSD.ORG> Cc: Dima Dorfman <dima@unixfreak.org>, current@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: vm_pager_(de)allocate and vm_mtx Message-ID: <20010526094220.2443E380E@overcee.netplex.com.au> In-Reply-To: <20010526010239.G17514@superconductor.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > * Dima Dorfman <dima@unixfreak.org> [010525 22:22] wrote: > > Is there a reason vm_pager_allocate acquires vm_mtx itself if > > necessary but vm_pager_deallocate does not? At the moment, detaching > > an md(4) disk will panic the system with a failed mtx_assert in > > vm_pager_deallocate. This can be fixed one of two ways: > > vm_pager_deallocate could be made to deal with vm_mtx itself like > > vm_pager_allocate does, or md(4) and any other drivers which call > > vm_pager_deallocate can be fixed to acquire vm_mtx. So which will it > > be? I'll supply patches for either case. > > Usually fixing the caller is better as it will catch people that > expect vm state to remain unchanged across several calls. It is a bit late now, but if we're going to push this to callers, I wish we had set up VM_LOCK() and VM_UNLOCK() macros or something so that we dont have to deal with fallout if something there changes (or gets conditionalized). At least use the macros outside of the vm/* and pmap.c files... On the same train of thought, perhaps GIANT_LOCK() and GIANT_UNLOCK() might have been an idea too. It would certainly have changed the code impact when the mutex api changed last time. It also gives us better 4.x porting targets because we can provide stub (do nothing) GIANT_LOCK()/UNLOCK() macros on 4.x. OK, we could do the same for mtx_lock()/unlock() too but I think the macros give us more flexability should we want to globally change the giant lock implementation at some point (or even locally add instrumentation for testing or whatever). Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 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?20010526094220.2443E380E>