Date: Mon, 10 Mar 2003 13:54:06 -0600 From: "Alan L. Cox" <alc@imimic.com> To: Sean Chittenden <sean@chittenden.org> Cc: arch@freebsd.org Subject: Re: Should sendfile() to return EAGAIN? [patch] Message-ID: <3E6CED5E.260E568E@imimic.com> References: <3E64FEA0.CCA21C7@imimic.com> <20030309135037.GK79234@perrin.int.nxad.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean Chittenden wrote: > > > 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?" > > Is this kind of a structure already in use someplace in the tree? I > poked around for a bit and couldn't find anything that'd suggest that > it's already been done. Do you know if/where I could poach code > that'd provide this functionality or would this be fresh bits that'd > that'd have to hit the tree? Andrew Gallatin outlined an implementation earlier in this thread. I've e-mailed you a patch that does the critical parts of what he outlined. > ... > Lastly, I couldn't find any bits to suggest how data coherency is > maintained. What's the mechanism in place that guarantee's this? > It's inherent. The same physical page is being shared by all invocations of sendfile() and the rest of the system. Observe that vm_page_lookup() is among the first VM operations performed. This checks to see if there is an existing physical page containing the data. If not, one is allocated and filled with data. This new page is then available to other sendfile() invocations and the rest of the system. If there is a coherence problem with sendfile(), it's the opposite of what you think: If someone mutates the file through, e.g., an mmap()ing, after a sendfile() had already started and returned, the data sent could include some of the new changes. (I think this is easiest to see if you imagine packet loss and retransmission occuring.) Alan 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?3E6CED5E.260E568E>