Date: Sun, 13 Jan 2013 10:53:18 -0700 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: arch@freebsd.org, John-Mark Gurney <jmg@funkthat.com>, David Xu <davidxu@freebsd.org>, toolchain@freebsd.org Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <1358099598.32417.33.camel@revolution.hippie.lan> In-Reply-To: <20130113175029.GA2561@kib.kiev.ua> References: <20130107182235.GA65279@kib.kiev.ua> <50EBAA1F.9070303@freebsd.org> <20130112230435.GJ1410@funkthat.com> <1358088614.32417.23.camel@revolution.hippie.lan> <20130113150633.GV2561@kib.kiev.ua> <1358099187.32417.31.camel@revolution.hippie.lan> <20130113175029.GA2561@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1358099598.32417.33.camel>