Date: Wed, 17 Jan 2001 14:09:34 -0700 From: Warner Losh <imp@harmony.village.org> To: Trent Nelson <tpnelson@switch.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Network I/O multiplexing questions. Message-ID: <200101172109.f0HL9Ys40809@harmony.village.org> In-Reply-To: Your message of "Wed, 17 Jan 2001 14:23:43 EST." <20010117142343.A1144@dhcp103-172-16-3.switch.com> References: <20010117142343.A1144@dhcp103-172-16-3.switch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20010117142343.A1144@dhcp103-172-16-3.switch.com> Trent Nelson writes: : 1. Is there any performance/efficiency gained when read and write : operations on multiple sockets are grouped together? That is, after : the I/O multiplexer function returns (i.e. select/poll/kevent), all : read operations on sockets are done together (say, encapsulated by : a thread, perhaps) and likewise for write operations. No. Not really. If the sockets are non-blocking, then doing a read is a fast operation. It will either return EWOULDBLOCK (in case something odd happened between the select and the read), or it will do a copyout of what data is there. You'd gain nothing by doing multiple of these at once. Likewise with nonblocking writes. It will either copy it in and return, or it will return EWOULDBLOCK. I've never hit scalibility problems in this area of the code. But I've also never tried to optimize things on a MP box in this area. That's the only way that having multiple outstanding read/writes makes any kind of performance sense. : 3. What conditions, if any, are used to deem whether a read or write : to a socket will block? Is there any quick and efficient way of : doing this in userspace? I'm assuming it has something to do with : the hi/lo watermarks of a socket and its associated I/O buffer. : : Can anyone point me to instances of kernel source code where a check : is made to see if a socket will block? select(), et al, will tell you if the woudl block. Make them non-blocking and you don't even have to worry about that. You get EWOULDBLOCK back from them. I can't point you at the source, however. For blocking sockets, reads block when there is no data and the connection is still good. Writes block when there's no kernel buffer space available for that socket. : 4. Currently, if a process blocks on network I/O, is it immediately : switched out of execution by the scheduler? Yes. Blocking is blocking. You can't run if you are blocked. That's why pthreads makes all its stuff non-blocking. : 5. Has anyone taken a look at the State-Threads API proposed by SGI? Nope. Warner 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?200101172109.f0HL9Ys40809>