Date: Sun, 13 Jan 2013 19:50:29 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Ian Lepore <freebsd@damnhippie.dyndns.org> 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: <20130113175029.GA2561@kib.kiev.ua> In-Reply-To: <1358099187.32417.31.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Qcw+NG9yjQzXdZsc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > > > >=20 > > > > Don't forget that there are arches out there w/ VIVT caches which w= ill > > > > probably eliminate most of the performance benifits if we have the = same > > > > page mapped writable in two different virtual addresses.. > > > >=20 > > >=20 > > > Even worse than eliminate the benefits, since multiple mappings with = one > > > writable disables caching on the whole page, there can be a big penal= ty > > > depending on what other data is nearby that suddenly becomes > > > uncacheable. I was initially very interested in the work to read sys= tem > > > clocks without a syscall until I realized it was going to suffer from > > > the same problem. > >=20 > > 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. >=20 > 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). >=20 > 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. >=20 > > Also, I suspect that even for arms, the writes are executed from the > > same core, which could simplify things even more. >=20 > 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). >=20 > -- Ian >=20 --Qcw+NG9yjQzXdZsc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ8vPkAAoJEJDCuSvBvK1BPwcP/2J8EpvsPnYRVj9X//KIpxb2 J7a48lmejktht9W7esIMWnBhrYl4bQCWTZuwnffqEwLlTCt5VsHwc1NGfDoigeV2 LQCiFuG/rSkTNpBDBJdNDDxTOmK+wLU6eLck9gj0INtgM7bVQUuP05gfU9utSjvG hCmLIN4nzkiSR9mSZWeJ7n2qq1Qy6k18dT2q68TAiXAscn3uuHxIJXmwLoahLrbb xlxorirXWn62lPFD9VPf0gRW98JzphKY/0oXseI/PhZjKD8ZpoPbnr9kmu1FrBZX Jtezg9eGHd3kH6KGdh1CZ9dxaR54MLcJDQCgN6bxWoJw6BO4hkclq/T6rWpvxOKh 8bXkS8OLsLCH3YYML01PEJtcf6bvkQ3CxuBt+apmkSpVDtRrel0SrT3S9xxPDUQc HD3agGo5FUthJnQzMhqpUHi4S3itA+Gk+3b26Wfza0RIJFp0lXPZ04dXq7RjfiPx B/EEWZb0/GU60OOUH+FoWp6q1jnhrzaOdJcs8pN8TmqpVnXL3z9ErGeOO4rZYspw 2YLYOfB1fpH4mcejqPyEbeSdp1XjUhq3h2CRHVQGjWk0dynosvCnekW/IXsxb4ev OwxUL8NKR3LBj2pnnqbAShB1t+yw3kknl1wuP4ytIaccpAQqizx/sHbw7eDql/ev LP3E/y31ymppF3lj16gz =GCvl -----END PGP SIGNATURE----- --Qcw+NG9yjQzXdZsc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130113175029.GA2561>