Date: Mon, 3 Jan 2000 10:57:52 -0800 From: "Scott Hess" <scott@avantgo.com> To: "Kip Macy" <kip@lyris.com>, "Steffen Merkel" <d_f0rce@gmx.de> Cc: <freebsd-hackers@freebsd.org> Subject: Re: Kernel threads Message-ID: <007401bf561c$6ff51930$1e80000a@avantgo.com> References: <Pine.SOL.4.05.9912270929080.24373-100000@luna.lyris.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kip Macy <kip@lyris.com> wrote:
> The words "POSIX threads" only describes the API. It says nothing about
> the implementation. On FreeBSD they are non-preemptive user level threads
> (your main was never yielding so the thread you launched did not get any
> time). On Linux they are processes sharing the same virtual memory space,
> and are referred to as kernel threads. For compute bound activities you
> want kernel threads to spread the computation over multiple processors.
> For I/O bound activities you want user level threads so you can minimize
> the context switch overhead.
As currently implemented, this last is only partially true. For I/O bound
activities you want user level threads for any I/O that can block - in
particular, _not_ disk I/O. As I mentioned in another thread ("Status of
kernel threads"), disk I/O _always_ blocks, which means that the current
userland threading library effectively serializes disk access, which is a
tremendous loss compared to kernel threads.
The best fix I've thought of thus far (other than async I/O, which I
understand isn't ready for prime time) would be to have a number of kernel
threads to handle never-blocking I/O. If the file descriptor can do
blocking I/O, throw it into the select() loop, but if it can't, throw the
system call into a queue for a pool of seperate kernel threads to run it.
This pool should definitely be bigger than the number of CPUs available,
because aggregate disk I/O gets more efficient as you increase the number
of outstanding requests.
Later,
scott
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?007401bf561c$6ff51930$1e80000a>