On Tue, 12 Oct 1999 22:55:12 -0700, Dan Kegel <dank@alumni.caltech.edu>
said:
> I'd like an opinion on whether the overhead of a
> thread context switch could be avoided by adding
> a kind of nonblocking read feature to sendfile().
In 2.3, we can avoid a lot of the overhead by taking advantage of the
lazy-TLB features in the scheduler. Basically you just put the thread
into lazy-TLB mode inside the sendfile syscall, and there will be no
hardware context switches when the scheduler runs that process until the
end of the syscall.
> 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.
Yes, and in principle it would be possible to make the sendfile
completely asynchronous, essentially by doing the disk IO asynchronously
from a dedicated kernel thread.
> 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.)
A kernel-based async sendfile would be able to use that optimisation
automatically.
--Stephen
-
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/