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>