On Sat, Sep 14, 2013 at 12:14 AM, ольга крыжановская <olga.kryzhanov...@gmail.com> wrote: > The child gets a copy of the list of mappings (start, end, flags), but > does not touch, or walk, the tree which manages the individual pages. > Permission/access checking was already done by the parent process. > 1Gib mapped is no different from 10000000Gib mapped, in this case.
You have to be careful with the statement. Some Unix versions will not be affected by the fork() itself, but the page/vm daemon will get a message that a fork happened and start to flush any dirty pages for these two processes (parent and child). The goal is to prevent that if parent and child are working on the same mapped pages the copy-on-write can cause a page shortage in the local page cache (local to the two processes), which would then be allocated from the global pool. The garbage collection done by the page/vm daemon usually prevents local cache exhaustion, but at the cost of significantly interfering with benchmarks. The quick&dirty solution is to have an idle machine with ample memory, and then use sync;sync before running the benchmark. Glenn/David: This is only an issue with benchmarking, but not an issue for your code (and grep only reads pages so they get never dirty anyway). Irek _______________________________________________ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users