RE: Thread implementations...

Amsden, Zachary (amsdenz@aavid.com)
Thu, 25 Jun 1998 11:56:56 -0400

> > But too slow disks and not enough memory are directly
> > related problems. If the kernel has frequently used
> > disk files in the buffer cache, it still needs to copy
> > the data to the user space server, then copy it back
> > out onto a socket. With sendfile(), it can directly
> > send data from the buffer cache without any user space
> > involvement. In addition, we no longer need user
> > space buffers in the server, cutting down on useless
> > "memory duplication", allowing for more buffer cache.
>
> Improvements to mmap, etc. could theoretically achieve this
> without API changes. The question is whether such changes
> would be too CPU-heavy and/or difficult to make use of in the
> user-space server programs.
>
> --
> Erik Corry
I assume you are talking about something like:

caddr_t buf = mmap(0, len, PROT_READ | PROT_WRITE,
MAP_FILE | MAP_SHARED, ofd, 0);
mmap(buf, len, PROT_READ, MAP_FIXED | MAP_FILE |
MAP_SHARED, ifd, 0);

So the two mmap overlap and automatically copy
data. This has two drawbacks:
1) It requires us to specify the number of bytes
to be written and map this into our address
space (mapping could be a big problem with
large >1gb files).
2) It requires the kernel to search through
the memory map for the process, and check
for overlaps (possibly multiple!), whereas
sendfile can attach redirection information
directly to the FD structure.

mmap() does have significant overhead as Linus
pointed out, and sendfile looks more easily
flexible.

Zach Amsden
amsden@andrew.cmu.edu

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu