Date: Sun, 30 Nov 2003 09:45:02 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: "Christopher M. Sedore" <cmsedore@maxwell.syr.edu> Cc: threads@freebsd.org Subject: RE: KSE system scope vs non system scope threads Message-ID: <Pine.GSO.4.10.10311300937260.4461-100000@pcnet5.pcnet.com> In-Reply-To: <32A8B2CB12BFC84D8D11D872C787AA9A515DB1@EXCHANGE.forest.maxwell.syr.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Nov 2003, Christopher M. Sedore wrote: > > From: Daniel Eischen [mailto:eischen@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10311300937260.4461-100000>