Performance issue

[Suleiman Souhlal]

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()
> 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):

zZzZ:~/py% LD_LIBMAP="libpthread.so.1=libc_r.so.5" ktrace -t c python  
heapsort.py 10000 > /dev/null && kdump -T | grep sigprocmask
   2991 python   1115698354.240301 CALL  sigprocmask 
(0x1,0x2810a820,0xbfbfea60)
   2991 python   1115698354.240304 RET   sigprocmask 0
   2991 python   1115698354.240307 CALL  sigprocmask(0x3,0x2810a830,0)
   2991 python   1115698354.240308 RET   sigprocmask 0
zZzZ:~/py%

compare with libpthread:
zZzZ:~/py% ktrace -t c python heapsort.py 10000 > /dev/null && kdump - 
T | grep -c sigprocmask
92114
zZzZ:~/py%

Is this a bug in libc_r?

--
Suleiman Souhlal     | ssouhlal at vt.edu
The FreeBSD Project  | ssouhlal at FreeBSD.org