On Sun, 2013-01-13 at 19:50 +0200, Konstantin Belousov wrote: > On Sun, Jan 13, 2013 at 10:46:27AM -0700, Ian Lepore wrote: > > On Sun, 2013-01-13 at 17:06 +0200, Konstantin Belousov wrote: > > > On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote: > > > > On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote: > > > > > David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800: > > > > > > and can not be freed until process is exited, the page is doubly > > > > > > mapped into in kernel and userland, accessing the shared data > > > > > > in kernel has zero overhead though. > > > > > > > > > > Don't forget that there are arches out there w/ VIVT caches which will > > > > > probably eliminate most of the performance benifits if we have the > > > > > same > > > > > page mapped writable in two different virtual addresses.. > > > > > > > > > > > > > Even worse than eliminate the benefits, since multiple mappings with one > > > > writable disables caching on the whole page, there can be a big penalty > > > > depending on what other data is nearby that suddenly becomes > > > > uncacheable. I was initially very interested in the work to read system > > > > clocks without a syscall until I realized it was going to suffer from > > > > the same problem. > > > > > > Since only kernel writes to the shared page, it should be not a problem. > > > At least there is a specific point where you can insert the neccessary > > > cache flush commands. > > > > With VIVT cache, all mappings of a page must be uncacheable no matter > > which one is writable. It applies even if all the mappings belong to > > the kernel (this is why the wired writable pages in the buffer cache > > kill executable performance with VIVT caches). > > > > There's no way to keep a VIVT cache coherent when there are multiple > > mappings, because of the virtual indexing: you write to a page, then do > > a flush based on that page's virtual address, and there's no way find > > cache lines which alias the same physical memory using different virtual > > addresses to flush them too. > No, you do know all the mapping addresses in this special case. > > The shared page is mapped at the fixed user address, and at some > kernel address. You obviously need to flush both cache lines. > > > > > > Also, I suspect that even for arms, the writes are executed from the > > > same core, which could simplify things even more. > > > > The arm chips that are affected by this don't have multiple cores (at > > least, I don't think there are any VIVT cache multi-core arms, it's > > probably not even possible). > > > > -- Ian > >
But as soon as you establish the second mapping, the code in pmap.c automatically remaps all existing mappings as uncacheable. It would be some pretty big work to special-case that for a few mappings where the kernel "knows what it's doing." -- ian _______________________________________________ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"