Fast sigblock (AKA rtld speedup)

[Ian Lepore]

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.

> 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