Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Jul 2004 15:08:41 -0500
From:      Alan Cox <alc@cs.rice.edu>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/alpha/alpha pmap.c src/sys/amd64/amd64 pmap.c         src/sys/i386/i386 pmap.c src/sys/vm vm_page.c
Message-ID:  <20040729200841.GF18577@cs.rice.edu>
In-Reply-To: <Pine.NEB.3.96L.1040729154004.46374J-100000@fledge.watson.org>
References:  <20040729131040.F32601@pooker.samsco.org> <Pine.NEB.3.96L.1040729154004.46374J-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 29, 2004 at 03:41:03PM -0400, Robert Watson wrote:
> On Thu, 29 Jul 2004, Scott Long wrote:
> 
> > >    - Enable recursion on the page queues lock.  This allows calls to
> > >      vm_page_alloc(VM_ALLOC_NORMAL) and UMA's obj_alloc() with the page
> > >      queues lock held.  Such calls are made to allocate page table pages
> > >      and pv entries.
> > 
> > My understanding is that recursive mutexes are quite expensive.  Is
> > recursion a common occurrance now, and is there a good way to
> > profile/measure these paths? 
> 
> No opinion on the change itself, but just to clarify this wording a little
> for those reading who don't follow the locking work blow-by-blow: flagging
> a mutex as recursive itself is not expensive, but the act of recursing the
> mutex is expensive. 
> 

I've benchmarked these changes on alpha, amd64 and i386 under
buildworld.  The overhead is small.

Also, recursion on the mutex will be rare, occurring under conditions
of an empty or near-empty free list.

Alan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040729200841.GF18577>