Date: Tue, 4 Mar 2003 17:08:37 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Sean Chittenden <sean@chittenden.org> Cc: "Alan L. Cox" <alc@imimic.com>, arch@freebsd.org Subject: Re: Should sendfile() to return ENOBUFS? Message-ID: <20030304170837.A10281@unixdaemons.com> In-Reply-To: <20030304215118.GJ79234@perrin.int.nxad.com>; from sean@chittenden.org on Tue, Mar 04, 2003 at 01:51:18PM -0800 References: <3E64FEA0.CCA21C7@imimic.com> <20030304215118.GJ79234@perrin.int.nxad.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 04, 2003 at 01:51:18PM -0800, Sean Chittenden wrote: > > The current sf_buf implementation has a simple problem that could > > account for your frequent blocking. Let me describe an extreme > > example that will make it clear. Suppose you have a web server that > > delivers nothing but a single file of 8 pages, or 32K bytes of data, > > to its clients. Here's the punchline: If you had 1,000 concurrent > > requests, you could wind up allocating 8,000 sf_bufs. Given that > > the main purpose of the sf_buf is simply to provide an in-kernel > > virtual address for the page, one sf_buf per page should suffice. > > Sf_bufs are already reference counted. So, the principle change > > would be to add a directory data structure that could answer the > > question "Does this page already have an allocated sf_buf?" > > This is an excellent suggestion and one that I hadn't even thought of, > thank you. You're right in assuming that I'm sending out only a few > hundred files per server to many thousands of clients, so this would > be ideal in terms of performance. The problem that I can see with > this is, "what happens when a file changes on disk?" Some how the > page of data needs to be flushed and re-read. For files that are > constantly in transit, their ref count would never hit zero so the > data sent would never change (in theory, or it would mix/match pages > from the new and old file: a problem not encountered with the current > sendfile() implementation). Shutting down the server and waiting for > the buffers to clear isn't a valid option in my book or with the > possibility of out of sequence pages makes sendfile() something of a > data integrity liability. > > Since the various pages types are all aligned, caching of sf_buf's > along with the above directory structure would be quite a bit more > efficient for my case, but possibly too efficient. Is there a > mechanism for reseting highly used, but changed file pages? There > could very likely is a way of doing this, but I'm not familiar with > it. What about only re-using the already allocated page if the timestamp for the last modification matches the currently stored one? (i.e., store the timestamp in the auxilary structure). I'm not sure this would work in all cases, but it would serve as an OK compromise; or maybe I'm just overlooking something? > -sc > > -- > Sean Chittenden -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org 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?20030304170837.A10281>