> could you (or someone else) elaborate on the issues with sendfile and
> asynch sendfile ? I'm curious..
sure..
> The current sendfile() is blocking right, so you basically need a fork()
> for serving a file ? And that an asynch sendfile would start the
> operation, return immediately, kernel fiddles with pages and sockets, and
> delivers a signal when done ?
It doesn't have to be blocking, it can return EAGAIN. That will make
sense when zero copy gets here for big machines, but its current point is
to reduce the syscall overhead of i/o by blocking and doing it all in one
go.
> And this is faster than using non-blocking separate write()'s from mmap'ed
> files in a select() loop (single thread model).
yeah. less churn and no mmap() overhead.
> If so, what does the sigio patches you mention do ?
the sigio patches are a different beast entirely. they add siginfo
structs for poll events on sockets. So you get sigio signals when things
happen to sockets and you get siginfo structs with them that says what fd
it happened to and just what it was that happened. that last part is why
all this is so cool. You get single quick notifications when something
happens, rather than spinning in poll()/select(). Its an efficient way of
doing i/o across lots of file discriptors in one context of execution.
the async sendfile stuff is yet another beast. imagine us doing this non
blocking sigio event engine, spinning on lots of sockets. we want to deal
with lots of data, more than will sit in the socket queues so we have to
spin on read/write and falling back to the i/o engine when it would block,
the io engine tells us when we can continue. with async sendfile,
however, we could simply issue the sendfile() and get an event when its
done (say, POLL_OUT or something on the descriptor).
-- zach
- - - - - -
007 373 5963
-
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/