KSE system scope vs non system scope threads

[Daniel Eischen]

On Sun, 30 Nov 2003, Christopher M. Sedore wrote:
> 
> From: Daniel Eischen [mailto:eischen at vigrid.com]
> >
> >Define what you think is degradation.  Process scope threads run in the
> >same KSEG.  They are all kept in the same priority-based run-queue.
> >If you have other threads that have equal or higher priority than
> >the network threads in question, they will/may run before those
> >threads.  All it takes is one thread that doesn't block (CPU-bound)
> >to eat away at the time allotment for your other threads.
> >
> >If a remote host is down and a thread can't connect to it, that thread
> >should block allowing other threads to run.  Are you using blocking
> >or non-blocking connects?
> 
> 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.

You should configure your mailer to wrap lines on outgoing mail...

Are you using cancellation at all?  I just noticed that libkse doesn't
seem to have a cancellation point for connect().

Are you doing anything in signal handlers that you shouldn't be
doing?

Other than that, it sounds like a locking problem in the kernel.
A thread blocked in connect() in the kernel shouldn't prevent
upcalls allowing other threads to run.  It sounds like the upcalls
aren't happening...

-- 
Dan Eischen