cvs commit: src/sys/i386/i386 pmap.c

Mike Silbersack silby at silby.com
Fri Oct 29 15:51:36 PDT 2004


On Fri, 29 Oct 2004, John Baldwin wrote:

> On Friday 29 October 2004 03:10 pm, Alan Cox wrote:
>>   Implement per-CPU SYSMAPs, i.e., CADDR* and CMAP*, to reduce lock
>>   contention within pmap_zero_page() and pmap_copy_page().
>
> Cool.  One note: I think you have to move the sched_pin before the lookup in
> the sysmaps_pcpu[] table so you don't migrate to another CPU if you get an
> interrupt after you've locked the sysmap.  I'm curious if can get rid of the
> sysmaps lock altogether actually.  It might require a critical section to do
> so though, and zero'ing page(s) is probably too long to defer interrupts.
>
> -- 
> John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/

I think we really need some sort of light-weight critical_enter that 
simply assures you that you won't get rescheduled to another CPU, but 
gives no guarantees beyond that.

Here's where I would make use of it:  arc4random().  For better 
performance, we could have one set of arc4's state per CPU.  To do that 
right now, I'd have to put a mutex on each bucket, so it wouldn't be much 
more efficient than it is now with its single mutex.  A critical_enter 
would allow me to skip locking, but that sounds like it's potentially far 
more expensive.  But, if we had some delay_me_but_dont_reschedule_me() 
operation that was cheap, I could call that and avoid doing any locking 
whatsoever.

Er, wait - I guess I'm forgetting something, there exists the potential 
for the interrupt that preempted whatever was calling arc4random to also 
call arc4random, thereby breaking things...

Instead, how about this - could per-CPU mutexes be implemented?  In that 
mode, mutexes wouldn't use atomic ops, because they'd only ever be used by 
a specific processor, thereby eliminating the need for atomic ops.  The 
second modification would be that they set a per-CPU flag somewhere which 
would tell the scheduler not to reawaken the sleeping kernel thread unless 
it was on the same CPU it started on.

Maybe the "wake things on their original processor" flag could be a global 
per-CPU variable that is incremented whenever a mutex with the LOCAL_ONLY 
flag is acquired, and decremented when such a mutex is released.

Mike "Silby" Silbersack


More information about the cvs-all mailing list