Messages in this thread | | | From | (Alan Cox) | Subject | Re: Kernel Threads: Dr. Russinovich's response | Date | Tue, 12 Jan 1999 21:03:43 +0000 (GMT) |
| |
> blocked an a select() waking up when only one is able to successfully perform > the accept() would certainly appear to be a significant performance issue. My
Poor scaling of poll/select semantics is a well known problem. You are doing setups for the waiting each time anyone returns. Note its possible to write a select_begin() select_do() select_end() syscall set to keep poll like semantics but scale more
> question is, is this a valid criticism of the kernel implementation or simply an > out of scope criticism that is an example of poor application design? I would
Its an example of why poll has problems. Sun have been doing a lot of work on poll/select scaling.
> Solaris. Are my expectations too high and are the criticisms brought up by Dr. > Russ potentially going to impact me in this area?
Im not sure. I don't think his signal ones are completely right, but it is true that for pthreads and the I/O stuff you may ultimately want a "queue async I/O and dont make threads for it" and certainly the ability to do CLONE_SHARE_SIGNALS for POSIX style pthreads would be good - Im sure Ulrich would have a chunk to say on this and the Linuxthreads hackers.
My primarily contention is with the scale of problem he portrays rather than the actual points he identifies.
He does not however seem to me to be an idiot.
Alan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |