"Zhihui Zhang" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
