From owner-freebsd-arch Mon Mar 3 16:12:37 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9586C37B401; Mon, 3 Mar 2003 16:12:35 -0800 (PST) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2599C43FA3; Mon, 3 Mar 2003 16:12:33 -0800 (PST) (envelope-from hiten@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.7/8.12.1) with ESMTP id h240CUjL041476; Mon, 3 Mar 2003 19:12:30 -0500 (EST) Received: (from hiten@localhost) by angelica.unixdaemons.com (8.12.7/8.12.1/Submit) id h240CUOS041475; Mon, 3 Mar 2003 19:12:30 -0500 (EST) (envelope-from hiten) Date: Mon, 3 Mar 2003 19:12:30 -0500 From: Hiten Pandya To: Sean Chittenden Cc: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return ENOBUFS? Message-ID: <20030304001230.GC36475@unixdaemons.com> References: <20030303224418.GU79234@perrin.int.nxad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030303224418.GU79234@perrin.int.nxad.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD i386 X-Public-Key: http://www.pittgoth.com/~hiten/pubkey.asc X-URL: http://www.unixdaemons.com/~hiten X-PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sean Chittenden (Mon, Mar 03, 2003 at 02:44:18PM -0800) wrote: > I've got a cluster of busy servers and have now exhausted the number > of sf_buf's available. top(1) reports that applications using > sendfile(2) are spending quite a bit of time in the 'sfbufa' state > blocking even though the socket is non-blocking. I'd consider this a > pretty nice bug and that sendfile(2) should return ENOBUFS instead of > blocking on a non-blocking call. Right now if sf_buf_alloc() returns > NULL, it is assumed that the call was sent a signal and was > interrupted. So I have a two fold question: > > 1) Should sendfile(2) block on a non-blocking socket when there are no > sf_buf's available? > > I don't think it should. sendfile(2) should return ENOBUFS and let > the user land process continue working even though the kernel is > constrained for sf_buf's. > > 2) Will changing the sendfile() call to return ENOBUFs break source > compatibility across sendfile() implementations? > > I'm pretty amazed that other performance mongers haven't run across > this problem and noticed this before under high load conditions. > > If there is a precedent, I'm tempted to suggest that we break ranks > because: > > *) the current behavior is pretty clearly not "the right thing" > *) is pretty clearly broken, and > *) is causing me no end of headaches (using writev() is a terrible > alternative to sendfile()). FWIW, there are many other parts of the sys/ tree where ENOBUFS or any error code is not returned in the case of mbuf allocation, or something on those lines, best candidate for this is the sys/nfsserver code. (Sorry for being a little offtopic...) Cheers. -- Hiten Pandya (hiten@unixdaemons.com, hiten@uk.FreeBSD.org) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message