From owner-freebsd-arch Tue Nov 30 18:24:55 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 430C714CD1 for ; Tue, 30 Nov 1999 18:24:52 -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 DAA16997 for ; Wed, 1 Dec 1999 03:24:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA74686 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 03:24:52 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1D37414CD1 for ; Tue, 30 Nov 1999 18:24:47 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA28925; Tue, 30 Nov 1999 18:24:46 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 18:24:46 -0800 (PST) From: Matthew Dillon Message-Id: <199912010224.SAA28925@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> <199911301732.JAA25846@apollo.backplane.com> <38441379.D8CD6CCD@newsguy.com> <199911301829.KAA26530@apollo.backplane.com> <38442193.931386B6@newsguy.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> that when you finish up tallying all the cpu the application uses, it :> is going to be nearly the same whether the application serializes the :> system calls (i.e. unthreaded) or doesn't serialize the system calls. :> From the point of view of the UNIX scheduler. : :No, not at all. For example think of an application with two :processes: one does i/o on a tcp socket and the other :number-crunches data. It gets converted to threads, so that it is :now just one process. Whenever the process "blocks" in the kernel :doing i/o, instead of being put to sleep control is returned to it, :and it spends the rest of it's quanta doing number-crunching. I believe I mentioned the kernel caching issue with I/O. Just because you are making a syscall does *not* mean you are getting the benefit of I/O scheduling and does *not* mean that you will block, only that you might block. Over the years kernels have been heavily optimized to disassociate I/O from the process requesting the I/O. For example, FreeBSD has TCP buffers in the kernel and issues read-ahead on its disks, over NFS, and so forth. If the kernels were not so heavily optimized to disassociate I/O then you would be right. But since they are, I do not think you will see the difference in effect that you expect. :The scheduler will not identify that process as one who does i/o. : :But... whatever. I'll just wait and see. : :-- :Daniel C. Sobral (8-DCS) -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message