Update: Debox sendfile modifications

silby_at_silby.com

Date: Tue, 4 Nov 2003 11:02:35 -0600 (CST)
To: Vivek Pai <vivek@CS.Princeton.EDU>


---
Suppose that sendfile is called to send to a non-blocking socket, and that
it detects that the page(s) required are not in memory, and that disk I/O
will be necessary.  Instead of blocking, sendfile would call a sendfile
helper kernel thread (either by calling kthread_create, or by having a
preexisting pool.)  After dispatching this thread, sendfile would return
EWOULDBLOCK to the caller.  Note that only a limited number of threads
would exist (perhaps 8?), so, if all threads were busy, sendfile would
have to block like it does at present.
Once the I/O was complete, the thread would call sowakeup (or whatever is
called typically when a thread is now ready for writing) for the socket in
question.  The application would call sendfile, like normal, but this time
everything would succeed because the page would be in memory.
---
If such a feature were implemented, it might have the same increased
performance effect that your new return value does, except that it would
require no modification for a non-blocking sendfile based application to
take advantage of it.
Alan, would this be possible from the VM system's perspective?  Is it safe
to assume that once the page in question was in the page cache that it
would hang around long enough for the second sendfile call to access it
before it is paged back out again?
Thanks,
Mike "Silby" Silbersack
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

Update: Debox sendfile modifications

Relevant Pages