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>
>