From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 17:53:22 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 30DECBAE; Sun, 13 Jan 2013 17:53:22 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id F3056158; Sun, 13 Jan 2013 17:53:21 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0DHrL7C058501; Sun, 13 Jan 2013 10:53:21 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0DHrIGw000975; Sun, 13 Jan 2013 10:53:18 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Fast sigblock (AKA rtld speedup) From: Ian Lepore To: Konstantin Belousov 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> Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Jan 2013 10:53:18 -0700 Message-ID: <1358099598.32417.33.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, John-Mark Gurney , David Xu , toolchain@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 17:53:22 -0000 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