Simon Richter wrote: > Hi, > >> 1) mmap() call actually doesn't map whole memory (mmap() has successfully mmap'ed 23 GiB, >> of course I have no such amounts of memory on my desktop); process memory are untouched at >> all; > > This is implementation defined behaviour. > >> 2) mmap() call doesn't grow a file attached to it, file size stays untouched directly >> after mmap(); > > This is implementation defined behaviour. > >> 3) when writing to mmap'ed region, file size become maximum of offsets that were used for >> writing. > > This is implementation defined behaviour. Yes, probably. Though very clever. > For example, the following behaviour would also be legal: > > - on mmap(), allocate 2 GiB of memory, load the current file contents into > it, extend the file on disk to 2 GiB. mmap(2) says that exact 'length' bytes have to be shared, and nothing said about what will be if file size is smaller than 'length' specified in the mmap() call. It's even don't clear is it allowed to call mmap() in this case... > - on msync/munmap/process exit, write the 2 GiB out to disk. Yes. But also unspecified (see comment for mmap()). Also, I've just found interesting comment to MAP_POPULATE flag, which enables read-ahead of file and disable future page faults. This may be interpreted that in other cases read-ahead disabled and enlarging real memory (and grow of file) should be only on page faults... Yes, only "may". I really want to find reliable documentation about this aspects of mmap(). -- Eugene V. Lyubimkin aka JackYF
Attachment:
signature.asc
Description: OpenPGP digital signature