From owner-freebsd-arch@FreeBSD.ORG Mon Jan 7 20:27:19 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 DFBDE88D; Mon, 7 Jan 2013 20:27:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3AA493DB; Mon, 7 Jan 2013 20:27:19 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id r07KREqv078357; Mon, 7 Jan 2013 22:27:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua r07KREqv078357 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id r07KREiw078356; Mon, 7 Jan 2013 22:27:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 7 Jan 2013 22:27:14 +0200 From: Konstantin Belousov To: Julian Elischer Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <20130107202714.GY82219@kib.kiev.ua> References: <20130107182235.GA65279@kib.kiev.ua> <50EB2DA1.5090306@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6BJIGhnDLgQ8Wrmm" Content-Disposition: inline In-Reply-To: <50EB2DA1.5090306@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, 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: Mon, 07 Jan 2013 20:27:19 -0000 --6BJIGhnDLgQ8Wrmm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 07, 2013 at 12:18:41PM -0800, Julian Elischer wrote: > On 1/7/13 10:22 AM, Konstantin Belousov wrote: > > Below is the forward of the patch for which I failed to obtain a private > > review. Might be, the list generates more responses. > > > > Our rtld has a performance bootleneck, typically exposed by the images > > with the lot of the run-time relocation processing, and by the C++ > > exception handling. We block the signals delivery during the rtld > > performing the relocations, as well as for the dl_iterate_phdr(3) (the > > later is used for finding the dwarf unwinding tables). > > > > The signal blocking is needed to allow the rtld to resolve the symbols > > for the signal handlers in the safe way, but also causes 2 syscalls > > overhead per each rtld entry. > > > > The proposed approach allows to shave off those two syscalls, doubling > > the FreeBSD performance for the (silly) throw/catch C++ microbenchmark. > > > > Date: Mon, 13 Aug 2012 15:26:00 +0300 > > From: Konstantin Belousov > > > > ... > > > > The basic idea is to implement sigprocmask() as single write into userm= ode > > address. If kernel needs to calculate the signal mask for current threa= d, > > it takes into the consideration non-zero value of the word at the agreed > > address. Also, usermode is informed about signals which were put on hold > > due to fast sigblock active. > > > > As I said, on my measurements in microbenchmark that did throw/catch in > > a loop, I see equal user and system time spent for unpatched system, and > > same user time with zero system time on patched system. > > > > Patch can be improved further, e.g. it would be nice to allow rtld to f= all > > back to sigprocmask(2) if kernel does not support fast sigblock, to pre= vent > > flag day. Also, the mask enforced by fast sigblock can be made configur= able. > > > > Note that libthr already blocks signals by catching them, and not using= rtld > > service in the first line handler. I tried to make the change in the sp= irit > > of libthr interceptors, but handoff to libthr appears too complicated to > > work. In fact, libthr can be changed to start using fast sigblock inste= ad > > of wrapping sigaction, but this is out of scope of the proposal right n= ow. > Is there any danger that an upriveliged user program can trick the kernel > into doing anything it shouldn't by manipulating either the agreed upon > address or the contents of the mask at the address? (even reading > something by seeing what sigs get masked) I do not see how would anything like this possible. >=20 > This was an issue with the M:N threading package and resulted in extra=20 > syscalls > to get around the problem. (I forget the details). Would be great to dig up the details indeed. I cannot comment otherwise. --6BJIGhnDLgQ8Wrmm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ6y+iAAoJEJDCuSvBvK1BaL4P/1vDmzlkJ6vxLZOwmTGbnoRe kaidamizUqMmlB2Fp4ruR2+6QeLn7oY2J0wSi7vtH/s+tynuQVSgfUgfxrqo68Lw 0cI4IWu/8TekYFLKlk3rDvpeHz8u3A3gzQOPXXwkutv07ZswJFN9moevMeAp+FA6 Kjh8VGzMaJACXnKk3qeSZEKWuyGYkcNA0xuY0TxtL4z6G6R856u2owmM1KA4iyC5 L9ZdaH2ZPCM8FWxJOBYbM7sIT4M99X9WB86RKGTBM7BgZdXG2yBU8f9KCTz4wkpP E9k985BJAcHLV8sf/1NQKG6ozMGRvCe1WAL2FoQ/7Cadr55ZbT8aPgh4xKcfKmWG v7FX3xhMZ11pufznNaJ05VChK/dnOM7EhXqIaV7nA99NTt5PebGbNVqCu16RxaUo hWuBDwN//JUmKGQz4Gzu/eVJLsOlKFGUX5AooskaG3+Dl6OL9sPcG9EfhAxLQRm6 VFOJ1jrfb+Ab3PEu44CYugl7OHIu3+rcXGNPI+mTLp3DmNEYes7u234fmO6aAqBl 8KWKf23WTdJjYRTrUSP6R/EKnfOi8yNVdCKXERn5ZPutYIQpTF+LuQRwyE4ct7do UMYTjXsVvu1DdY9LpMDp4fnXd4yKZaKXDs6pxkhvNriqvZvXB4Nmf/JCpxZEY1h5 JXDUqsOBRBj4FBKNV9A5 =JIfl -----END PGP SIGNATURE----- --6BJIGhnDLgQ8Wrmm--