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