KSE system scope vs non system scope threads

[Christopher M. Sedore]

Sorry for the long delay in responding.  We upgraded to 5.2Beta before we did this trial, and after installing on our SMP machines (that's all we've been using for tests), we haven't been able to get them stable--we see panics within 15 minutes of boot once our threaded process begins.  To continue testing, we rebuilt the kernel uniproc.  The change back to v1.18 of thr_spinlock improves the situation but we're still seeing some degradation, but it is shorter and shallower now than it was.  I need to do more thorough testing before I can claim that it is related to a KSE issue--it could be some other performance oddity.
 
(I'm not approaching any of the kernel limits.  I'm peaking around 30-40 threads.)
 
As a side-note, could anyone offer any ideas as to why I'm getting an error EAGAIN from sendfile when not using non-blocking sockets?  As far as I could determine, the only case where I should see EAGAIN is a NB socket.  I'm seeing this happen part way through a send (200k into a 500k send in one instance).  I'm expecting to have to set up a kernel debugger to trace it out since a scan of the kernel source doesn't show any simple reason why this might happen.
 
-Chris

________________________________

From: David Xu [mailto:davidxu at freebsd.org]
Sent: Sun 11/30/2003 6:25 PM
To: Christopher M. Sedore
Cc: deischen at freebsd.org; threads at freebsd.org
Subject: Re: KSE system scope vs non system scope threads



Christopher M. Sedore wrote:

>I'm using blocking connects.  Degradation is I should be moving ~5-7MB/sec (and I do if I don't try to connect to any hosts that are down).  Once I do, I see fluctuations from ~15-20KB/sec (note: KB) to 3-5MB/sec, somewhat associated with when the connects happen.  Running libthr, I move 6-7MB/sec consistently (until everything hangs up showing sigwait as the status in top, anyway).  System scope threads turn in numbers from 5-6MB/sec.  (Note I don't have any hang problems under KSE, only libthr.)
>
>On Monday I'm going to try David Xu's suggestion of trying v1.18 of thr_spinlock.c to see if that helps.
>
> 
>
I don't know if you hit a hard limit in kernel. The hard limit is
sysctl kern.threads.max_threads_per_proc, default is 150, it means
system only allows 150 threads to be blocked in kernel, if you hit the
limits, then performance will be degraded.

David Xu

>-Chris
>_______________________________________________
>freebsd-threads at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-threads
>To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"
>
> 
>