Subject: Re: SMP improvements for pmap
To: Chuck Silvers <chuq@chuq.com>
From: Stephan Uphoff <ups@stups.com>
List: port-i386
Date: 05/30/2003 20:38:28
Thanks, I corrected my patch and pmap_enter() now updates the mapping 
atomically.

Unfortunately I might have found another issue.

Can the following functions: 
                               pmap_enter(),
                               pmap_remove(),
                               pmap_unwire(),
                               pmap_write_protect(),

execute concurrently for the same virtual address range using 
the kernel pmap ( pmap_kernel() ) ?

My feeling is that there are some circumstances - and that fixing
the resulting race conditions in these functions will require some
ugly locking logic. 

Could someone please tell me that I am wrong ;-)

I am also looking for some good benchmarks.
CPU usage for sequential block input in bonnie drops from 15-16%
to 10-11% using the patched pmap on my SMP machine. (Same throughput)
However bonnie is clearly not the right benchmark.

	Stephan

> 
> this may actually be a problem for wired mappings.
> though that's more a sign of a deficiency in the design of wired mappings
> (ie. that the pmap must treat them specially) than a bug in any given
> pmap implementation.
> 
> -Chuck
> 
> 
> On Wed, May 21, 2003 at 05:40:07PM -0700, Jason Thorpe wrote:
> > 
> > On Wednesday, May 21, 2003, at 04:44  PM, Stephan Uphoff wrote:
> > 
> > >pmap_enter() does not replace the old mapping atomically with the new 
> > >mapping
> > >             if the old mapping points to a managed page.
> > >	     Other CPUs might observe va to be unmapped (pte == 0) before
> > >             pmap_enter sets the new mapping.
> > >
> > >	     I don't think this is a problem.
> > >             If it is, the pve handling needs to be changed.
> > 
> > I don't think it's a problem, either.  In this case, the worst that 
> > could happen is that the other CPU would take a page fault, but then 
> > would block in the upper layers of the VM code.  By the time it 
> > unblocked, the only damage it could do would be to enter the same 
> > mapping again.
> > 
> >         -- Jason R. Thorpe <thorpej@wasabisystems.com>
>