In a web server, one can use sigwaitinfo() (or poll())
to efficiently multiplex many clients onto one thread.
If the client asks for a flat file, one can use sendfile()
to avoid the overhead of copying the data to userspace and back.
To avoid the problem of sendfile() blocking all the
clients when it has to read from disk, one can have
worker threads do all the sendfiles.
It would be nice if one didn't have to hand the request to
a worker thread if the file is already in memory,
i.e. if sendfile() was able to return EWOULDBLOCK if
the read operation would block because the data wasn't in core.
(There's no need for this read to trigger an asynchronous
readahead, 'cause the worker thread would then issue a
blocking read somehow.)
Is it worth proposing a new kernel feature to optimize
this one case, or should I relax and just hand everything
to worker threads, and trust that the extra context switches
won't be a burden? How would the worker thread do a blocking
read if the file's in nonblocking mode, anyhow -- I don't
want the overhead of switching modes, nor of maintaining a
second file descriptor for the file.
Should I just be asking for aio_sendfile() instead? Guess so...
- Dan
cf. http://kernelnotes.org/lnxlists/linux-kernel/lk_9906_03/msg00508.html
-- (The above is my opinion alone, and not that of my employer)- 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/