From owner-freebsd-arch@FreeBSD.ORG Sun Jan 13 17:46:32 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 E4BEE987; Sun, 13 Jan 2013 17:46:32 +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 71FDDFA; Sun, 13 Jan 2013 17:46:31 +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 r0DHkUEu058107; Sun, 13 Jan 2013 10:46:30 -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 r0DHkROi000960; Sun, 13 Jan 2013 10:46:28 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Fast sigblock (AKA rtld speedup) From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20130113150633.GV2561@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> Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Jan 2013 10:46:27 -0700 Message-ID: <1358099187.32417.31.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:46:33 -0000 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