From owner-freebsd-arch Tue Mar 4 2: 3:49 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 8C3D537B401; Tue, 4 Mar 2003 02:03:47 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4AB243FB1; Tue, 4 Mar 2003 02:03:41 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h24A3cmF081402; Tue, 4 Mar 2003 13:03:38 +0300 (MSK) Date: Tue, 4 Mar 2003 13:03:38 +0300 (MSK) From: Igor Sysoev X-Sender: is@is To: Sean Chittenden Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Should sendfile() to return ENOBUFS? In-Reply-To: <20030303224418.GU79234@perrin.int.nxad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Mon, 3 Mar 2003, Sean Chittenden 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? sendfile() can block on a non-blocking socket at least in two cases: 1) sf_buf's exhaustion (as you have described), 2) and reading file page from the disk. In these cases we could return: 1) EAGAIN for both cases, 2) or ENOBUFS for sf_buf's exhaustion and EAGAIN (or new special error) for reading file page (after initiating disk transfer of course). ENOBUFS (and new special error) could be enabled via sendfile() flag parameter, which currently unused and should be zero, so we would not break source and even binary compatibility. But there is the one problem - how to notify user-level code about readiness of these events, especially with EAGAIN ? select()/poll()/kevent() (or kevent() only) should check not only socket reasiness but readiness of the read operation (if it was initiated) and free sf_buf's (if we exhausted them last time). Igor Sysoev http://sysoev.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message