Date: Thu, 29 Oct 1998 15:16:40 -0500 (EST) From: HighWind Software Information <info@highwind.com> To: eischen@vigrid.com Cc: current@FreeBSD.ORG, eischen@vigrid.com, lists@tar.com Subject: Re: Thread Scheduler bug Message-ID: <199810292016.PAA02026@highwind.com> In-Reply-To: <199810291610.LAA11080@pcnet1.pcnet.com> (message from Daniel Eischen on Thu, 29 Oct 1998 11:10:06 -0500 (EST))
next in thread | previous 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. -Rob 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?199810292016.PAA02026>