From owner-freebsd-arch@FreeBSD.ORG Fri Jan 11 10:23:17 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ABBC4973; Fri, 11 Jan 2013 10:23:17 +0000 (UTC) (envelope-from davidxu@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 833211C7; Fri, 11 Jan 2013 10:23:17 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0BANGKh059347; Fri, 11 Jan 2013 10:23:16 GMT (envelope-from davidxu@freebsd.org) Message-ID: <50EFE830.3030500@freebsd.org> Date: Fri, 11 Jan 2013 18:23:44 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Fast sigblock (AKA rtld speedup) References: <20130107182235.GA65279@kib.kiev.ua> <20130111095459.GZ2561@kib.kiev.ua> In-Reply-To: <20130111095459.GZ2561@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 11 Jan 2013 10:23:17 -0000 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 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 usermode >> address. If kernel needs to calculate the signal mask for current thread, >> 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 fall >> back to sigprocmask(2) if kernel does not support fast sigblock, to prevent >> flag day. Also, the mask enforced by fast sigblock can be made configurable. >> >> 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 spirit >> of libthr interceptors, but handoff to libthr appears too complicated to >> work. In fact, libthr can be changed to start using fast sigblock instead >> 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 David > 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. > 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.