Date: Thu, 29 Oct 98 10:01:53 -0500 From: "Richard Seaman, Jr." <lists@tar.com> To: "current@FreeBSD.ORG" <current@FreeBSD.ORG>, "Daniel Eischen" <eischen@vigrid.com>, "info@highwind.com" <info@highwind.com> Subject: Re: Thread Scheduler bug Message-ID: <199810291601.KAA14098@ns.tar.com>
next in thread | raw e-mail | index | archive | help
On Thu, 29 Oct 1998 10:07:20 -0500 (EST), Daniel Eischen wrote: >> I'm worried about the thread scheduler. Here is a disturbing test >> program out for folks to try. >> >> As you can probably guess, we are now battling the scheduler because >> some of our application's threads are getting seriously starved by >> other threads. >> >> I'm compiling on 3.0 with the latest libc_r. >> >> This program works fine on IRIX, Solaris, and (gasp..) Linux. >> >> Isn't FreeBSD supposed to handle this without the explicit yield() call? > >It looks like setitimer isn't working as the threads library >expects it to. The timer isn't going off, but it seems to be >set properly. > >If you manually kill -VTALRM the running process, you'll see >the markTimeThread run. > >I placed a print statement in the threads library where the >timer is set, and it is being called with the proper values >(100msec time slice). > >Why does heavy IO stop the timer from going off and the >process from being signaled? 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. 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?199810291601.KAA14098>