Date: Tue, 30 Nov 1999 18:24:46 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads and the scheduler Message-ID: <199912010224.SAA28925@apollo.backplane.com> 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>
index | next in thread | previous in thread | raw e-mail
:> 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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912010224.SAA28925>