From owner-freebsd-stable@FreeBSD.ORG Tue May 10 05:24:10 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 54E6616A4EE; Tue, 10 May 2005 05:24:10 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E246643D5D; Tue, 10 May 2005 05:24:09 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j4A5O8fm004739; Tue, 10 May 2005 01:24:09 -0400 (EDT) Date: Tue, 10 May 2005 01:24:08 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Suleiman Souhlal In-Reply-To: <361776BC-F969-4F88-8656-E75A5D967186@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: Tue, 10 May 2005 05:24:10 -0000 On Tue, 10 May 2005, Suleiman Souhlal wrote: > Hello, > > On May 9, 2005, at 7:21 PM, Daniel Eischen wrote: > > > 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() ^^^^^^^^^^ or any thread library. > > 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). > > Processes linked with libc_r NEVER call the syscall, once they have > started (after rtld-elf): [...] > Is this a bug in libc_r? No, libc_r wraps execve() and a lot of other syscalls that libpthread or libthr don't need to. Take a look at libc_r/uthread/uthread_execve.c and you will see it sets the signal mask before exec()ing. -- DE