Fast sigblock (AKA rtld speedup)

[Ian Lepore]

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