Date: Mon, 3 Mar 2003 19:12:30 -0500 From: Hiten Pandya <hiten@unixdaemons.com> To: Sean Chittenden <seanc@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: Should sendfile() to return ENOBUFS? Message-ID: <20030304001230.GC36475@unixdaemons.com> In-Reply-To: <20030303224418.GU79234@perrin.int.nxad.com> References: <20030303224418.GU79234@perrin.int.nxad.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030304001230.GC36475>