Date: Mon, 9 May 2005 19:47:08 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Suleiman Souhlal <ssouhlal@freebsd.org> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: Performance issue Message-ID: <Pine.GSO.4.43.0505091941130.27904-100000@sea.ntplx.net> In-Reply-To: <Pine.GSO.4.43.0505091907060.27904-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0505091941130.27904-100000>