Date: Fri, 29 Oct 2004 17:51:30 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 pmap.c Message-ID: <20041029174131.A6530@odysseus.silby.com> In-Reply-To: <200410291549.17355.jhb@FreeBSD.org> References: <200410291910.i9TJAlNf089795@repoman.freebsd.org> <200410291549.17355.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041029174131.A6530>