Messages in this thread | | | From | "Steven Schaefer" <> | Subject | mmap(.., .., PROT_READ, MAP_PRIVATE, .., ..) functionality question | Date | Thu, 6 Mar 2003 23:40:02 -0500 |
| |
Please email me directly (or CC me) since I am not subscribed to the mail list.
I have a question on the functionality of mmap() when used with PROT_READ, and MAP_PRIVATE flag.
Currently I am reading in the entire contents of a file into memory and processing it thru "zlib" compression library. In order to create RFC1952 compatible data the file's contents has to be read once by the compression routine and once by the checksum routine. "zlib" provides a simple implementation where it uses mmap() to map the file into memory and passes that address off to the two routines. This brings up my design consideration and thus my question.
Doesn't mmap(), mind you with PROT_READ and MAP_PRIVATE, first copy the contents of the file into the swap space and then when the data is accessed into physical RAM before the CPU can get to it? If so, in essence wouldn't I be doubling the disk access time??? I have found numerous messages talking about mmap() but only with read/write considerations.
I'm trying to decide whether or not using read() to copy the contents into system memory (heavy on the physical memory) is worth the sacrifice of having the extra disk access (light on the physical memory). So how does mmap() handle the mapped file?
Imagine for a moment it does not first copy the file contents to swap space. The fact that I would need to read the data twice, once for each function; wouldn't the memory access to the file contents cause mmap() to access the file twice from the hard drive be a draw back or does it somehow cache it in memory after the first access? If it did cache it, is it going to cache it on the swap partition or in memory?
I list a few links that I found references to mmap() discussions, that of course didn't specifically answer my question.
http://groups.google.com/groups?q=mmap+group:mlist.linux. *&start=180&hl=en&lr =&ie=UTF-8&selm=linux.kernel.1007839431.371.0.camel%40quinn.rcn.nmt.edu&rnum =185
http://groups.google.com/groups?q=mmap+group:mlist.linux. *&start=70&hl=en&lr =&ie=UTF-8&selm=linux.kernel.991739488742.20020313181735%40spylog.ru&rnum=75
http://groups.google.com/groups?q=mmap+group:mlist.linux. *&start=90&hl=en&lr =&ie=UTF-8&selm=linux.kernel.1781804867952.20020314122715%40spylog.ru&rnum=9 6
http://groups.google.com/groups?q=mmap+group:mlist.linux. *&start=160&hl=en&lr =&ie=UTF-8&selm=linux.kernel.5.1.0.14.2.20020603141650.01acc8c0%40mira-sjcm- 3.cisco.com&rnum=169
http://groups.google.com/groups?q=mmap+group:mlist.linux. *&start=180&hl=en&lr =&ie=UTF-8&selm=linux.kernel.9spg3c%247bb%241%40penguin.transmeta.com&rnum=1 87
http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.1/0884.html
http://groups.google.com/groups?q=mmap+group:mlist.linux.*&hl=en&lr =&ie=UTF-8&selm=linux.kernel.861732271654.20020313161718%40spylog.ru&rnum=3
http://groups.google.com/groups?q=mmap+group:mlist.linux. *&start=40&hl=en&lr =&ie=UTF-8&selm=linux.kernel.3B269B5D.35A554A9%40scali.no&rnum=50
- 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/
| |