From owner-freebsd-bugs@FreeBSD.ORG Sun Jun 30 03:20:01 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.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 68F54803 for ; Sun, 30 Jun 2013 03:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4A3981FB8 for ; Sun, 30 Jun 2013 03:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5U3K0Y6018714 for ; Sun, 30 Jun 2013 03:20:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5U3K0gi018712; Sun, 30 Jun 2013 03:20:00 GMT (envelope-from gnats) Date: Sun, 30 Jun 2013 03:20:00 GMT Message-Id: <201306300320.r5U3K0gi018712@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Konstantin Belousov Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Konstantin Belousov List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 03:20:01 -0000 The following reply was made to PR kern/131597; it has been noted by GNATS. From: Konstantin Belousov To: Jilles Tjoelker Cc: bug-followup@FreeBSD.org, John Baldwin , guillaume@morinfr.org, theraven@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Sun, 30 Jun 2013 06:12:32 +0300 --suMD1gxl821dzEEX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 29, 2013 at 11:53:35PM +0200, Jilles Tjoelker wrote: > On Fri, 28 Jun 2013 20:45:38 +0300, Konstantin Belousov wrote: > > On Fri, Jun 28, 2013 at 01:38:39PM -0400, John Baldwin wrote: > > > On Friday, June 28, 2013 1:17:21 pm Konstantin Belousov wrote: > > > > On Fri, Jun 28, 2013 at 08:47:55AM -0400, John Baldwin wrote: > > > > > Looking at this again, the patch committed in 178807 is just > > > > > wrong and should be reverted. There is no state in rtld that > > > > > needs to be protected via a write lock. GCC is too lazy to use > > > > > their own locking to protect shared state between threads and > > > > > wants the runtime linker to enforce this. Their justification > > > > > that glibc doesn't allow concurrent execution of this isn't a > > > > > valid excuse. For an API like this that just walks a list and > > > > > invokes a callback, if the callback manipulates shared state > > > > > owned by the caller, the caller should be responsible for > > > > > sychronizing access to it, not rtld! >=20 > > > > > Instead I think we should apply the patch in the original GCC > > > > > bug to our in- tree GCC and to our GCC ports. This should > > > > > remove the sigprocmask calls and not penalize other users of > > > > > dl_iterate_phdr() for GCC's poor behavior. >=20 > > > > In other words, we should become knowingly incompatible with the st= ock > > > > GCC and with other consumers of dl_iterate_phdr(), like libunwind ? > > > > E.g. libunwind ability to unwind from the signal handler relies on > > > > this behaviour. >=20 > > > Does libunwind depend on rtld single-threading to lock state shared > > > with other threads? If it does it should manage that itself. If > > > GCC and/or libunwind want to share arbitrary state between threads, > > > or protect state from being accessed by a signal handler, then GCC > > > and/or libunwind should manage that. rtld can't possibly (and > > > shouldn't) know the rules about how that state that is private to > > > GCC/libunwind is managed. >=20 > > libunwind depends on the dl_iterate_phdr() signal-safety. >=20 > > > What if you had a consumer of this that wanted to access the state > > > outside of the callback? Then it already has to manage all the > > > locking itself to be safe anyway. >=20 > > > Put another way, requiring dl_iterate_phdr() to providing locking > > > for consumers would be equivalent to code assuming that C++'s > > > for_each() template in provided locking to callers. > > > That is entirely upside-down. >=20 > > I think I should revive the fast sigprocmask patch. >=20 > We could add a version of dl_iterate_phdr that does not call > sigprocmask() and use it in patched GCC/libunwind/etc. The patched GCC > and libunwind can then avoid the sigprocmask call (possibly at the cost > of less efficient caching) while unpatched GCC and libunwind continues > to work. As I said, libunwind relies on the signal blocking behaviour to be able to unwind from the signal handler. >=20 > I am a bit concerned, though, that this is only needed for the > unthreaded programming environment. libthr has an efficient method for > postponing signals that avoids system calls. Moving that mechanism to > libc, although it is a bit hard, may be an option. Well, the right answer then is, in fact, to merge libc and libthr. I implemented ELF filters as the first required step, but did not progressed the task further. IMO the merge is mostly mechanical, the complication is due to the fact that the work should be done in branch and takes a lot of time. As result, the libc and libthr changes during development are conflicting and have to be constantly resolved. --suMD1gxl821dzEEX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRz6IfAAoJEJDCuSvBvK1BMyMP/Agnvo15YjGSs3Vj3Dqy/ffE o1Pq3xxRSry2E2IUI04OlHR4223LMeUx/oSg5uNoZog3n0V7hWB2jYI3Kyo2n6cH 0AP6kQTezqnrq8jDsEKeaUZIPqqZ7O1H86pnBNamMmUHfQ7+MzbCpt+D9EXPGmsR It5xn3SNFCvzqi8brsJXEir4XMQjFedj07BDjPlQsXsqqLkpDegHsJ7VCBpVStfn I4IAWwzJ8oiGrnEsRFKaYq1HvGvQp2S51WnzUt2Uv6PCpz0pAfRoIeYV8az879OQ 33xU8eMceds8FnOtPsiIrNL/OO70tMPD2QHEFVLS5ltM/NTmabnFPl/5/2nMDZXs rik3A3DjjDMbHBENc1nU/2YQZertFsCrsOLb6h5sYS66NjF4yhPdq9EQtFoECOcZ Y73YhZgQxdTxIHNXCsRbWDzc2fMnhp5sDSfKtBBzJDV3u1lfYiSFk9FO/4LpK/lJ eyu4waFaqRKtWdAJPetMRjdAwotYBQcYEIHnSGEgIA11K6f2benF4a4X6eC8gnpi thAMteMEc7Nu3kCEgQz+DJUlj1gQqMbsvVzt/fW5lCPZ00whD1kpvvxPVnFTQ+mw uQngRaBGY5sNDXV5YZoXS45ltwcLHCX5MbhKWHV1shGCKW0QxNTEQdqEzaJUw/xA +9lwCRYbNzzWsHJmx6CS =tlId -----END PGP SIGNATURE----- --suMD1gxl821dzEEX--