> >
> >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
>
Suleiman Souhlal wrote:
Hello,
On May 9, 2005, at 3:54 PM, Daniel Eischen wrote:
On Tue, 10 May 2005, Peter Jeremy wrote:
On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote:
I have what I think is a serious performance issue with fbsd 5.3
release. I've read about threading issues, and it seems t
On Tue, 10 May 2005, Suleiman Souhlal wrote:
> Hi,
>
> On May 10, 2005, at 1:24 AM, Daniel Eischen wrote:
>
> > 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 s
Hi,
On May 10, 2005, at 1:24 AM, Daniel Eischen wrote:
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.
Couldn't we do the same thing in libpthr
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 chang
On Mon, 9 May 2005, Jonathan Noack wrote:
> On 05/09/05 18:47, Daniel Eischen wrote:
> >>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 ther
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), th
On 05/09/05 18:47, Daniel Eischen wrote:
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 t
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 ass
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
Hello,
On May 9, 2005, at 3:54 PM, Daniel Eischen wrote:
On Tue, 10 May 2005, Peter Jeremy wrote:
On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote:
I have what I think is a serious performance issue with fbsd 5.3
release. I've read about threading issues, and it seems to me that
that is what I
On 5/9/2005 1:30 PM, Jonathan Noack wrote:
On 5/9/2005 12:31 PM, Pete French wrote:
5.3 ships with SMP turned on, which makes lock operations rather
expensive on single-processor machines. 4.x does not have SMP
turned on by default. Would you be able to re-run your test with
SMP turned off?
I ju
Daniel Eischen wrote:
> {sig}setjmp(), {sig}longjmp(),
A very wild guess.. python is using setjmp/longjmp to implement
continuations, tailcalls, or any mechanism similar to that and using
that in a loop?
mkb.
___
freebsd-stable@freebsd.org mailin
On Tue, 10 May 2005, Peter Jeremy wrote:
> On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote:
> >I have what I think is a serious performance issue with fbsd 5.3
> >release. I've read about threading issues, and it seems to me that
> >that is what I'm looking at, but I'm not confident enough to
On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote:
>I have what I think is a serious performance issue with fbsd 5.3
>release. I've read about threading issues, and it seems to me that
>that is what I'm looking at, but I'm not confident enough to rule out
>that it might be a hardware issue, a ke
On 5/9/2005 12:31 PM, Pete French wrote:
5.3 ships with SMP turned on, which makes lock operations rather
expensive on single-processor machines. 4.x does not have SMP
turned on by default. Would you be able to re-run your test with
SMP turned off?
I just ran a test here with SMP turned of on 5
On Mon, 9 May 2005, Suleiman Souhlal wrote:
> Hello,
>
>
> I ran ktrace(1) on it, and it appears that python keeps calling
> sigprocmask() continually:
>
> 673 python 0.07 CALL sigprocmask(0x3,0,0x811d11c)
> 673 python 0.05 RET sigprocmask 0
> 673 python 0.09 CALL
On Mon, May 9, 2005 1:06 pm, Scott Long said:
> 5.3 ships with SMP turned on, which makes lock operations rather
> expensive on single-processor machines. 4.x does not have SMP turned on by
> default. Would you be able to re-run your test with SMP turned off?
This is what i get on my system, wh
Hello,
On May 9, 2005, at 1:31 PM, Pete French wrote:
5.3 ships with SMP turned on, which makes lock operations rather
expensive on single-processor machines. 4.x does not have SMP
turned on by default. Would you be able to re-run your test with
SMP turned off?
I just ran a test here with SMP tur
Scott Long wrote:
> First of all, make sure that you have WITNESS and INVARIANTS off in your
> kernel. You might also want to recompile your kernel with the SMP
> option turned off.
I can confirm this.
I just rerun it on RELENG_5_4 as of yesterday and got
136.52 real80.29 user
> 5.3 ships with SMP turned on, which makes lock operations rather
> expensive on single-processor machines. 4.x does not have SMP
> turned on by default. Would you be able to re-run your test with
> SMP turned off?
I just ran a test here with SMP turned of on 5.4-RC4 (GENERIC) I got the
follow
Ewan Todd wrote:
5.3 ships with SMP turned on, which makes lock operations rather
expensive on single-processor machines. 4.x does not have SMP
turned on by default. Would you be able to re-run your test with
SMP turned off?
I'm pretty sure there's no SMP in this kernel.
#cd /usr/src/sys/i38
>
> 5.3 ships with SMP turned on, which makes lock operations rather
> expensive on single-processor machines. 4.x does not have SMP
> turned on by default. Would you be able to re-run your test with
> SMP turned off?
>
I'm pretty sure there's no SMP in this kernel.
#cd /usr/src/sys/i386/c
Ewan Todd wrote:
Whereas, the typical result for the new rig looked more like
105.36 real71.10 user33.41 sys
...
10548 involuntary context switches
First of all, make sure that you have WITNESS and INVARIANTS off in your
kernel. You might also want to recompile your ker
> >
> >Whereas, the typical result for the new rig looked more like
> >
> > 105.36 real71.10 user33.41 sys
> > ...
> > 10548 involuntary context switches
> >
> >
>
> First of all, make sure that you have WITNESS and INVARIANTS off in your
> kernel. You might also wan
@freebsd.org
Subject: Re: Performance issue
> Whereas, the typical result for the new rig looked more like
>
> 105.36 real71.10 user33.41 sys
...
> 10548 involuntary context switches
Now I just ran this test myself. This machine is a 2.4 gig P4 with
hyperth
> Whereas, the typical result for the new rig looked more like
>
> 105.36 real71.10 user33.41 sys
...
> 10548 involuntary context switches
Now I just ran this test myself. This machine is a 2.4 gig P4 with
hyperthreading enabled. Much as I am an AMD fan, I would expect
At 11:00 AM 09/05/2005, Ewan Todd wrote:
Here's the background. I just got a new (to me) AMD machine and put
5.3 release on it. I'd been very happy with the way my old Intel
There have been quite a few changes since 5.3. If you are starting fresh, I
would strongly recommend going to 5.4 RC4. The
Ewan Todd wrote:
Hi All,
I have what I think is a serious performance issue with fbsd 5.3
release. I've read about threading issues, and it seems to me that
that is what I'm looking at, but I'm not confident enough to rule out
that it might be a hardware issue, a kernel configuration issue, or
som
29 matches
Mail list logo
