From owner-freebsd-stable@FreeBSD.ORG  Mon May  9 23:47:09 2005
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
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 D452416A4EB; Mon,  9 May 2005 23:47:09 +0000 (GMT)
Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 4D5B143D5E; Mon,  9 May 2005 23:47:09 +0000 (GMT)
	(envelope-from deischen@freebsd.org)
Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11])
	j49Nl8r9018240;	Mon, 9 May 2005 19:47:08 -0400 (EDT)
Date: Mon, 9 May 2005 19:47:08 -0400 (EDT)
From: Daniel Eischen <deischen@freebsd.org>
X-X-Sender: eischen@sea.ntplx.net
To: Suleiman Souhlal <ssouhlal@freebsd.org>
In-Reply-To: <Pine.GSO.4.43.0505091907060.27904-100000@sea.ntplx.net>
Message-ID: <Pine.GSO.4.43.0505091941130.27904-100000@sea.ntplx.net>
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 <ewan@mathcode.net>
cc: Peter Jeremy <PeterJeremy@optushome.com.au>
cc: freebsd-stable <freebsd-stable@freebsd.org>
Subject: Re: Performance issue
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: Daniel Eischen <deischen@freebsd.org>
List-Id: Production branch of FreeBSD source code
	<freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2005 23:47:10 -0000

On Mon, 9 May 2005, Daniel Eischen wrote:

> On Mon, 9 May 2005, Suleiman Souhlal wrote:
> > 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.

[ ... ]

> 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).

As in something like this:

  http://people.freebsd.org/~deischen/kse/thr_sigmask.c.diffs

It has not been tested.

-- 
DE