From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 4 17:20:49 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94D9C16A4CE for ; Tue, 4 Nov 2003 17:20:49 -0800 (PST) Received: from mail.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1664C43FAF for ; Tue, 4 Nov 2003 17:20:48 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 21536 invoked from network); 5 Nov 2003 01:20:47 -0000 Received: from unknown (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 5 Nov 2003 01:20:47 -0000 Received: from hydrogen.funkthat.com (wluzyr@localhost.funkthat.com [127.0.0.1])hA51KkgP037693; Tue, 4 Nov 2003 17:20:46 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id hA51Kjwt037692; Tue, 4 Nov 2003 17:20:45 -0800 (PST) Date: Tue, 4 Nov 2003 17:20:45 -0800 From: John-Mark Gurney To: Mike Silbersack Message-ID: <20031105012044.GY558@funkthat.com> Mail-Followup-To: Mike Silbersack , Vivek Pai , freebsd-hackers@freebsd.org, Alan Cox 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> <1067183332.3f9bece4c0cf4@webmail.cs.princeton.edu> <3FA2C43E.3030204@cs.princeton.edu> <20031104104729.S1684@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031104104729.S1684@odysseus.silby.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-hackers@freebsd.org cc: Vivek Pai cc: Alan Cox Subject: Re: Update: Debox sendfile modifications X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2003 01:20:49 -0000 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."