Date: Sat, 27 Nov 1999 00:58:33 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Julian Elischer <julian@whistle.com> Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <383F7309.5D18949D@vigrid.com> References: <Pine.BSF.4.10.9911262111220.544-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > If the kernel automatically completes the KSEs, then the kernel is > > arbitrarily deciding the priority of the threads. There could be > > runnable threads with higher priority than any of the threads blocked > > in the kernel. > > That's Matt's argument. > > If we had a thread that was super High priority, we should have assigned > it a subproc (scheduling class) that was high priority. Then it wouldn't > be competing with the others. There's another problem too. If the kernel arbitrarily completes IO requests, then the UTS has no idea how much system time was spent for each thread. The UTS needs to know this in order to effectively schedule threads. There was a PR describing this problem in our threads library. Libc_r used to use ITIMER_VIRTUAL for timing, but IO bound threads would starve out other threads because their accrued run time didn't reflect the time spent in the system. I changed the timer to be ITIMER_PROF to fix the problem. If you hide time spent in the system from the UTS, the same thing can happen. I/O bound threads will starve out other threads. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?383F7309.5D18949D>