From owner-freebsd-arch Sat Nov 27 6:14:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6D83114CCF for ; Sat, 27 Nov 1999 06:14:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA07869 for ; Sat, 27 Nov 1999 15:14:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA52620 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 15:14:42 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 996F414D98 for ; Sat, 27 Nov 1999 02:20:21 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id CAA01287; Sat, 27 Nov 1999 02:20:17 -0800 (PST) Date: Sat, 27 Nov 1999 02:20:17 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <383F7309.5D18949D@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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