Messages in this thread | | | Date | Sat, 3 May 2003 14:52:26 +0200 (MEST) | From | Pål Halvorsen <> | Subject | Re: sendfile |
| |
On Fri, 2 May 2003, Mark Mielke wrote:
> On Fri, May 02, 2003 at 12:19:25AM -0400, Chris Friesen wrote: > > According to this: > > http://asia.cnet.com/builder/program/dev/0,39009360,39062783,00.htm > > using sendfile() is easier on the CPU due to less trashing of the TLB. > > Thanks for the link. It looks quite accurate. > > One question it raises in my mind, is whether there would be value in > improving write()/send() such that they detect that the userspace > pointer refers entirely to mmap()'d file pages, and therefore no copy > of data from userspace -> kernelspace should be performed. The pages > could be loaded and accessed directly (as they are with sendfile()) > rather than generating a page fault to load the pages. The TLB trashing > does not need to occur. > > I guess the first response to this question would be 'why not use > sendfile()? it already exists, and people have already begun to use > it...' > > My answer is that I don't like sendfile(). It is not-yet-standard, and > is fairly limited. I could just be naive, but I think that: > > write(fd, mmapped_file_pages, length); > > Could be transparently mapped to the sendfile() code in the kernel, > minimizing the benefit of sendfile() having its own system call. It all > comes down to optimization. The current implementation of mmap() is not > optimal where mmap()'d file pages are passed as data to system calls.
This is somewhat similar to what I want to do as well. As long as sendfile can have this, why cant we make write/send/... similar. Thus, removing the copy operation. Then, one can easier support streaming applications (or applications needing more control than sendfile)!
-ph
> mark
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |