Messages in this thread | | | Date | Mon, 04 Jun 2001 17:27:41 -0700 | From | Dan Kegel <> | Subject | re: disk-based fds in select/poll |
| |
Pierre Phaneuf <pp@ludusdesign.com> wrote: > It's fairly widely-known that select/poll returns immediately when > testing a filesystem-based file descriptor for writability or > readability. > > On top of this, even when in non-blocking mode, read() could block if > the pages needed aren't in core. sendfile() behaves in a similar way. > > What would be needed to alleviate this? > ... > I remember seeing a suggestion by Linus for an event-based I/O > interface, similar to kqueue on FreeBSD but much simpler. I'd just say > "I want it too!", ok? :-) > > SGI's AIO might be a solution here, does it use threads? I'm trying to > avoid context switching as much as possible, to keep the CPU cache as > warm as possible.
IMHO, you want AIO. SGI's is fine for now. I hear rumors that there will be something even better coming in 2.5, though I have no details.
Or you could use explicit userspace threads... say, divide up your network connections among 8 or so threads. Then if one thread blocks, the others are there to usefully soak up the CPU time.
Readiness events for readahead completion on disk files used to seem like a neat idea to me, but now AIO seems more appealing in the long run, since they handle random access properly.
- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |