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. Also, I suspect that even for arms, the writes are executed from the same core, which could simplify things even more.
pgpRq3ZqxpUAh.pgp
Description: PGP signature
