Date: Mon, 31 May 2010 01:43:02 +0000 (UTC) From: Alan Cox <alc@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/mips/mips pmap.c Message-ID: <201005310143.o4V1hBwl055470@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
alc 2010-05-31 01:43:02 UTC
FreeBSD src repository
Modified files:
sys/mips/mips pmap.c
Log:
SVN rev 208665 on 2010-05-31 01:43:02Z by alc
Merge portions of r208645 and supporting code from the i386 pmap:
When I pushed down the page queues lock into pmap_is_modified(), I created
an ordering dependence: A pmap operation that clears PG_WRITEABLE and calls
vm_page_dirty() must perform the call first. Otherwise, pmap_is_modified()
could return FALSE without acquiring the page queues lock because the page
is not (currently) writeable, and the caller to pmap_is_modified() might
believe that the page's dirty field is clear because it has not seen the
effect of the vm_page_dirty() call.
When I pushed down the page queues lock into pmap_is_modified(), I
overlooked one place where this ordering dependence is violated:
pmap_enter(). In a rare situation pmap_enter() can be called to replace a
dirty mapping to one page with a mapping to another page. (I say rare
because replacements generally occur as a result of a copy-on-write fault,
and so the old page is not dirty.) This change delays clearing PG_WRITEABLE
until after vm_page_dirty() has been called.
Fixing the ordering dependency also makes it easy to introduce a small
optimization: When pmap_enter() used to replace a mapping to one page with a
mapping to another page, it freed the pv entry for the first mapping and
later called the pv entry allocator for the new mapping. Now, pmap_enter()
attempts to recycle the old pv entry, saving two calls to the pv entry
allocator.
Revision Changes Path
1.57 +45 -34 src/sys/mips/mips/pmap.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201005310143.o4V1hBwl055470>