Date: Sat, 17 Mar 2012 18:49:51 -0500 From: Alan Cox <alc@rice.edu> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: Alan Cox <alc@FreeBSD.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233097 - head/sys/amd64/amd64 Message-ID: <4F65231F.1000101@rice.edu> In-Reply-To: <A64E77A8-291B-4DD9-9271-015DE8069F77@freebsd.org> References: <201203172204.q2HM4xBH088986@svn.freebsd.org> <A64E77A8-291B-4DD9-9271-015DE8069F77@freebsd.org>
index | next in thread | previous in thread | raw e-mail
On 03/17/2012 17:14, Nathan Whitehorn wrote: > > > On Mar 17, 2012, at 5:04 PM, Alan Cox wrote: > >> Author: alc >> Date: Sat Mar 17 22:04:58 2012 >> New Revision: 233097 >> URL: http://svn.freebsd.org/changeset/base/233097 >> >> Log: >> With the changes over the past year to how accesses to the page's dirty >> field are synchronized, there is no need for pmap_protect() to acquire >> the page queues lock unless it is going to access the pv lists. >> >> Reviewed by: kib > > Under what circumstances does the page queue lock actually have to be > held? You need it when you are manipulating the pvo_vlink lists. That said, we are at the point where the PPC/AIM pmap could define its own PVO list mutex and not (ab)use the page queues mutex for this purpose. Just do a straightforward, mechanical substitution, and you should be fine. > It looks like from this that I can remove the page queue lock from the > PPC/AIM pmap_protect() completely, but I don't have a good sense of it. Yes, you can this instant remove the acquisition and release of the page queues lock from this function.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F65231F.1000101>