From owner-freebsd-arch Tue Nov 30 9:33: 4 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 E237615805 for ; Tue, 30 Nov 1999 09:32:56 -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 SAA09105 for ; Tue, 30 Nov 1999 18:32:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA71405 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 18:32:55 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BCB0615805 for ; Tue, 30 Nov 1999 09:32:40 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA25846; Tue, 30 Nov 1999 09:32:39 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 09:32:39 -0800 (PST) From: Matthew Dillon Message-Id: <199911301732.JAA25846@apollo.backplane.com> To: "Daniel C. Sobral" Cc: freebsd-arch@freebsd.org Subject: Re: Threads and the scheduler References: <3842DBB5.8AFC9B6@newsguy.com> <199911292022.MAA08694@apollo.backplane.com> <3843D43E.4F40A642@newsguy.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Mmmm... that's not exactly what I'm worried about. I'm thinking of :applications which use threads to handle both i/o and cpu-bound :tasks. Our scheduler raises the i/o-bound tasks priority and lowers :cpu-bound tasks priority. With a program using threads to do both, :the scheduler would end up treating the process as cpu-bound and :lower it's priority. : :Ok, maybe that's fault of the application design, but still... :-) : :Processes with enough i/o-bound tasks to actually use up all quanta :before running out of threads will suffer from a similar fate. : :-- :Daniel C. Sobral (8-DCS) :dcs@newsguy.com :dcs@freebsd.org I don't think you have anything to worry about. A thread is going to go to sleep if it has nothing to do even if all the I/O is asynchronous (i.e. thread is mixing cpu and I/O bound elements). It isn't the I/O that raises the priority, it is the act of the process going to sleep that raises the priority. The basic characteristics of a program will not change whether it is threaded or not, because the program is still doing essentially the same task as it was before (just a little more efficiently). So if an unthreaded program tended to use 10% of the cpu before the same program threaded will also tend to use 10% of the cpu. You will wind up with something relatively close to what you had before in regards to the scheduling. Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message