From owner-freebsd-stable@FreeBSD.ORG Mon May 9 23:21:28 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F076516A4EB; Mon, 9 May 2005 23:21:28 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 752FC43D41; Mon, 9 May 2005 23:21:28 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j49NLR6m020888; Mon, 9 May 2005 19:21:27 -0400 (EDT) Date: Mon, 9 May 2005 19:21:27 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Suleiman Souhlal In-Reply-To: <4D923762-6562-440B-8456-EA404F7FDA44@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: Ewan Todd cc: Peter Jeremy cc: freebsd-stable Subject: Re: Performance issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2005 23:21:29 -0000 On Mon, 9 May 2005, Suleiman Souhlal wrote: > On May 9, 2005, at 3:54 PM, Daniel Eischen wrote: > > > The threading libraries don't play with the signal mask. In fact, > > libpthread has userland versions of sigprocmask() et. al. and won't > > even make the syscall() unless the threads are system scope. There > > is a special thread in libpthread that handles signals which does > > use the system sigprocmask(), but unless the application is > > making heavy use of signals in general, it shouldn't matter. > > I think I've found the problem: Python uses setjmp/longjmp to protect > against SIGFPU every time it does floating point operations. The > python script does not actually use threads, and libpthread assumes > non-threaded processes are system scope. So, it would end up using > the sigprocmask syscall, even though it doesn't really need to. > The diff at http://people.freebsd.org/~ssouhlal/testing/ > thr_sigmask-20050509.diff fixes this, by making sure the process is > threaded, before using the syscall. I don't think that patch is correct. You need the signal mask in the kernel to match in case of an exec() after a fork() for instance. If the application fork()'s, then changes the signal mask in the child (which is now single threaded), then the child exec()s, the mask is wrong. If the process wasn't linked to libpthread, then the longjmp() and setjmp() would still be calling the syscall, so it isn't the syscall itself that is making things slower. You'll notice that there are two calls to __sys_sigprocmask() in the section of code you have patched. You could eliminate the second call if you do some of what the remainder of the function does instead of returning early (the locks aren't needed and pending signals don't need to be run down). -- DE