Date: Thu, 29 Oct 1998 16:13:44 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: eischen@vigrid.com, info@highwind.com Cc: current@FreeBSD.ORG, lists@tar.com Subject: Re: Thread Scheduler bug Message-ID: <199810292113.QAA19289@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> > Possibly the VTALRM timer measures only time spent in user mode > > and not in kernel mode. This heavy I/O takes place almost entirely > > in kernel mode and it is the only process running. Therefore, very > > little user time is being accumulated. > > > > Possibly it you waited long enough, you'd still get the SIGVTALRM. > > If you add some user mode processing to the thread, you'll see > > the SIGVTALRM sooner. > > Yeah, I just figured this out (should pay closer attention to > the man pages). Seems like the profiling timer would be closer > to what we'd want (not to say the threads library should use > the profiling timer). A quick hack to replace occurrences of > SIGVTALRM with SIGPROF in the threads library seems to make > the test program work more correctly. > > Interesting analysis. This seems to be a very NASTY problem. If you > have a collection of threads that spend a lot of time in system space, > you can REALLY starve other threads. I can't imagine that this is a > rare occurance. > > Is using SIGPROF a viable alternative? Sounds a bit drastic. I doubt it, as it would probably break POSIX semantics. Threaded applications then wouldn't be able to use SIGPROF. A new signal or two, used only for the threads library would be better. I think Solaris uses a set of signals reserved just for the threads library. I think we're already max'd out with signals though. Is there any intention of allowing more than 32 signals? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810292113.QAA19289>