I have done the following test using boost::iostreams::mapped_file and encountered some page fault (detected using getrusage). The page faults in step 4 are something I could not understand.
- the file is in disk, the size is exactly 1 page (4096 bytes). I created
mapped_fileusing modereadwrite - I mapped the file and read the first byte. This generated a page fault as expected.
- I started another round the same as step 2. No page fault is observed, matches expectation
- I then write one byte to it and saw one minor page fault, which I could not understand why.
- I write another byte and no page fault is observed. Matches expectation again.
I think Step 3 already confirmed that the page is in physical memory. Then why did step 4 still generate a page fault? I only have some feeling that this might be related to copy-on-write, or related to PRIVATE vs SHARED mapping.
Can I assume that after step 2, the process has a virtual memory V that is mapped to the page cache C in the physical memory managed by the kernel? When writing to V, is C directly modified? Does this depends on whether PRIVATE or SHARED mapping is used?
