svn commit: r210846 - in head/sys/mips: include mips

Jayachandran C. c.jayachandran at
Wed Aug 11 05:51:20 UTC 2010

On Wed, Aug 11, 2010 at 10:36 AM, Jayachandran C.
<c.jayachandran at> wrote:
> On Fri, Aug 6, 2010 at 10:06 PM, Alan Cox <alc at> wrote:
>> The patch looks good.
>> While we're talking about software dirty bit emulation, I would encourage
>> you to look at two things:
>> 1. trap.c contains two copies of the same code for emulation.  I would
>> encourage you to eliminate this duplication by creating a
>> pmap_emulate_modified().
>> 2. Software dirty bit emulation is using pmap_update_page() to invalidate
>> the TLB entry on which the modified bit is being set.  On a multiprocessor,
>> this is going to make dirty bit emulation very costly because every
>> processor will be interrupted.  In principle, it should be possible and
>> faster to only flush the TLB entry from the current processor.  The other
>> processors can handle this lazily.  They either do not have that mapping in
>> their TLB, in which case interrupting them was wasted effort, or they do
>> have it in their TLB and when they fault on it they'll discover the dirty
>> bit is already set.  In fact, the emulation code already handles this case,
>> on account of the fact that two processors could simultaneously write to the
>> same clean page and only one will get the pmap lock first.
> I've made the changes suggested, the changes are attached.
> The first set of changes just re-arranges the pmap calls that use
> smp_rendezvous() on SMP, so that their per-cpu variants are also
> available to be called.  The first patch also has an optimization from
> Juli's branch, to call pmap_update_page in pmap_kenter only if the pte
> is valid.
> The second patch makes the changes suggested above. My testing shows
> no issues so far, but please let me know if you have any comments.

The second patch had an error  (noted by Neel, thanks!), I unlock
kernel_pmap, instead of pmap in a return path.  I will fix this before
check-in, more comments welcome.


More information about the freebsd-mips mailing list