Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Jan 2013 22:49:38 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        David Xu <davidxu@freebsd.org>
Cc:        arch@freebsd.org, toolchain@freebsd.org
Subject:   Re: Fast sigblock (AKA rtld speedup)
Message-ID:  <20130111204938.GD2561@kib.kiev.ua>
In-Reply-To: <50EFE830.3030500@freebsd.org>
References:  <20130107182235.GA65279@kib.kiev.ua> <20130111095459.GZ2561@kib.kiev.ua> <50EFE830.3030500@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--jYUWvSWTDpDT74zJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 11, 2013 at 06:23:44PM +0800, David Xu wrote:
> On 2013/01/11 17:54, Konstantin Belousov wrote:
> > On Mon, Jan 07, 2013 at 08:22:35PM +0200, Konstantin Belousov wrote:
> >> Below is the forward of the patch for which I failed to obtain a priva=
te
> >> 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 <kostikbel@gmail.com>
> >>
> >> ...
> >>
> >> The basic idea is to implement sigprocmask() as single write into user=
mode
> >> address. If kernel needs to calculate the signal mask for current thre=
ad,
> >> it takes into the consideration non-zero value of the word at the agre=
ed
> >> address. Also, usermode is informed about signals which were put on ho=
ld
> >> 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, a=
nd
> >> 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 =
fall
> >> back to sigprocmask(2) if kernel does not support fast sigblock, to pr=
event
> >> flag day. Also, the mask enforced by fast sigblock can be made configu=
rable.
> >>
> >> Note that libthr already blocks signals by catching them, and not usin=
g rtld
> >> service in the first line handler. I tried to make the change in the s=
pirit
> >> of libthr interceptors, but handoff to libthr appears too complicated =
to
> >> work. In fact, libthr can be changed to start using fast sigblock inst=
ead
> >> of wrapping sigaction, but this is out of scope of the proposal right =
now.
> >>
> >> Please comment.
> >
> > So there were no overly negative comments, and thanks to Alfred and Dav=
id
> > for useful notes.
> >
> > The patch at
> > http://people.freebsd.org/~kib/misc/rtld-sigblock.2.patch
> > is the commit candidate. Now kernel informs rtld about supprt for
> > fast_sigblock with new auxv flag. Rtld can operate on old (and possibly
> > future) kernels without fast_sigblock, rtld checks the auxv for
> > presence of the ELF_BSDF_FASTSIGBLK flag before use.
> >
>=20
> The patch looks fine to me. Sorry, I still have a question:
> if I found a process does not responsing to a signal, now should we
> check both its signal mask and fast block value ? but is there such
> a tool available ? for example, in gdb.

Fair enough.

I added the facility to export the address of the fast sigblock word
to the tools, and implemented the procstat extension to print the address
with -j. You can indeed use gdb to look up the content of the word
when debugging, after getting it address from procstat.

http://people.freebsd.org/~kib/misc/rtld-sigblock.3.patch

--jYUWvSWTDpDT74zJ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iQIcBAEBAgAGBQJQ8HriAAoJEJDCuSvBvK1BI/wP/i56RdjaKBiS48mkS24o2YHr
yQ+NCpZE6Wj1PI37MnL/gPOPZyqoGEdsqdhDRfG0+dhEf2X1NCnOhWWHIaq4V2BJ
CDhvpqLLU/Fd3N9N/JmaZvrHpZF7Bsvs36PLCAD7EChoX4KTnC9lEUqsfa9YUNuR
9eT7DmfSqGAcfUTlIs2EbudDI/EWkhXdx6PVAKGd6lBW74UQH6yeLrFJoB5ly6b9
dVEbufpcqy1OxbniM0BX9UgZUmbb3d3bE/tgrS/wrxo1gh4iMu5a2Ll/8zS6+PZm
kcJ6pvp+4rTdmUxrgfmSlwgN+NIQpXGFOWtTR4zgyjOgK2uUkbUd9qujBHwmLoFS
fJ7UIQCCyra3+GFPoEuRaHdrCMvEoR10J6zEHWN6TceIfei7FY0Qb2fbfRtW1If5
4p1tWoL0D+3lmO8aitdWQNIGEir4qXHQMFYW6zIBJC2qV8eMvxLW8uyCnq809vd7
5dmmwkybRR8n5vJQ2dXZwiWPF/K6o0WF+wI8bGMTAa4TO/TdKsy6AW1AtHOv33nO
8NChYxPM3s3YmjjKwp0qfrhHw7zacrooBPR3sHGpoDEMHSHsQESk5yOy0o63vSqG
jJWAus44Lij0aQOCy4KJmkE7K41g0bUuUumSW4+D0+noDegykndojE5ulvj7RmPN
z2GrZFFWTZd3O9NIbo7m
=1Olc
-----END PGP SIGNATURE-----

--jYUWvSWTDpDT74zJ--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130111204938.GD2561>