KSE system scope vs non system scope threads

[David Xu]

Christopher M. Sedore wrote:

>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.
>
Are there some signals should be processed while doing transfering or 
connecting,  I think spinlock revision 1.18
is still not perfect, it uses low level  thread lock,  and still 
prevents signals be processed by threads, probably
we should use mutex.

> 
>(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.
>  
>
I don't have any idea.

> 
>-Chris
>  
>
David Xu