From owner-freebsd-hackers Mon Jan 3 10:59: 3 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id AB72115214 for ; Mon, 3 Jan 2000 10:58:46 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 247; Mon, 3 Jan 2000 10:54:27 -0800 Message-ID: <007401bf561c$6ff51930$1e80000a@avantgo.com> From: "Scott Hess" To: "Kip Macy" , "Steffen Merkel" Cc: References: Subject: Re: Kernel threads Date: Mon, 3 Jan 2000 10:57:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kip Macy 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