Date: Fri, 4 Feb 2000 19:36:36 -0800 From: "Scott Hess" <scott@avantgo.com> To: "Zhihui Zhang" <zzhang@cs.binghamton.edu>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: FreeBSD Posix threads Message-ID: <19b001bf6f8a$349abf70$1e80000a@avantgo.com> References: <Pine.GSO.3.96.1000204121232.25825C-100000@sol.cs.binghamton.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
"Zhihui Zhang" <zzhang@cs.binghamton.edu> wrote: > (1) Some people say "For I/O bound activity, kernel threads are a really > bad idea". But I read the following passage from else where: > > Kernel threads perform better in I/O-intensive applications because system > call can be blocking for kernel threads (so there is only one > user-to-kernel and kernel-to-user transition per I/O operation rather than > two). > > So which one is the correct answer? I know there is only userland thread > in FreeBSD, but I would like to know the answer. Both. All I/O is not created equal. For blockable I/O (sockets, both TCP and UNIX domain, ttys, pipes, etc), userland pthreads are excellent. For disk I/O, they're less excellent because disk I/O is always ready to go, and you'll always block waiting for it. Not having multiple pending disk I/O requests can be killer. OTOH, that doesn't apply if your working set fits in memory. > (2) User threads are supposed to be faster than kernel threads in context > switch. But since we poll devices during each context switch, it is > actually slower (poll() is the extra system call). Is this correct? That's hard to say. If you use a "standard" thread-per-connection, then only the threads waiting for input contribute to the poll(). Threads that are working do not. Furthermore, a system call is not necessarily a cause for alarm - yet, that's a prime location for the kernel to decide to switch to another process, but it's not _required_ to do so. 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?19b001bf6f8a$349abf70$1e80000a>