Date: Fri, 29 Oct 2004 16:18:27 -0500 From: Alan Cox <alc@cs.rice.edu> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 pmap.c Message-ID: <20041029211827.GE16680@cs.rice.edu> 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, Oct 29, 2004 at 03:49:17PM -0400, John Baldwin wrote: > On Friday 29 October 2004 03:10 pm, Alan Cox wrote: > > alc 2004-10-29 19:10:47 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/i386/i386 pmap.c > > Log: > > 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. > If an interrupt and migration occurs, it could result in contention for the lock but not a correctness problem. However, what you suggest does have the virtue of making the code more obviously correctness. As far as using a critical section, how long is too long for deferring interrupts? I measured the cost of pmap_zero_page() at ~5400 cycles on a 400MHz FSB Xeon. The cost of pmap_copy_page() is much higher, but I don't recall what it is. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041029211827.GE16680>