Date: Tue, 4 Nov 2003 17:20:45 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: Mike Silbersack <silby@silby.com> Cc: Alan Cox <alc@cs.rice.edu> Subject: Re: Update: Debox sendfile modifications Message-ID: <20031105012044.GY558@funkthat.com> In-Reply-To: <20031104104729.S1684@odysseus.silby.com> References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <20031022082953.GA69506@rot13.obsecurity.org> <1066816287.25609.34.camel@boxster.onthenet.com.au> <20031022095754.GA70026@rot13.obsecurity.org> <xzpk76sc425.fsf@dwp.des.no> <1067183332.3f9bece4c0cf4@webmail.cs.princeton.edu> <3FA2C43E.3030204@cs.princeton.edu> <20031104104729.S1684@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Silbersack wrote this message on Tue, Nov 04, 2003 at 11:02 -0600:
> 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.
This would not work with kqueues as kevents are level triggered, not
edge... so, this idea is bad/broken. I don't even think it would work
with select since when you call select, it will check the availabilty
of writing at the select call time.. You'd have to add a flag to the
fd so mark it as delayed for another reason.. I don't think this feature
can be cleanly added w/o somehow tieing fd's together.
One call that I would like to see is a fd to fd copy. You pass in both
fd's with maybe a length, and then a kernel helper thread does the copy
or something. This would have other uses in that you can then "plumb"
pipes between programs in a more effecient manner... This would also
possibly fix/replace sendfile as sendfile isn't more different.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031105012044.GY558>