Date: Sat, 27 Nov 1999 02:20:17 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <Pine.BSF.4.10.9911270218430.544-100000@current1.whistle.com> In-Reply-To: <383F7309.5D18949D@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
ok well I'm only sketching out one solutionso don't feel that ai'm bullying you into anything.. in this scheme however there is nothing to say that we can't keep track of time spent in IO. On Sat, 27 Nov 1999, Daniel M. Eischen wrote: > 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?Pine.BSF.4.10.9911270218430.544-100000>