Fast sigblock (AKA rtld speedup)

[Konstantin Belousov]

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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130113/0ce6a481/attachment.sig>