cvs commit: src/sys/i386/i386 pmap.c
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
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-src