On 12/9/19 4:25 PM, Keith Medcalf wrote: >> You could still have fast forking without overcommitting, you’d just pay >> the cost in unreachable RAM. >> >> If I have 4 GB of RAM in the system, and the kernel takes 1 GB of that, I >> start a 2.5 GB user space process, and my process forks itself with the >> intent of starting an 0.1 GB process, that fork would have to fail if >> overcommitting weren’t allowed. > No, it wouldn't, and there is no overcommitment. You are creating a second > process that is using the same V:R mapping as the original process thus it is > consuming no more virtual memory after the fork operation than before (except > for the bytes to track the new process). You now have two execution paths > through the same mapping which may require more real memory working set, but > you have not increased the virtual memory size. That is until one of the > processes modifies a memory page in which case an additional virtual page > must be allocated to hold the modified page. > > Overcommittment occurs at the R level, not at the second V in the V:V:R > mapping. > > This is why shared libraries (and discontiguous saved segments) were > invented. It permits the per-process mapping (the first V in V:V:R) to use > already existing virtual pages (the second V in V:V:R) without increasing the > count of Virtual Pages. It is not overcommittment unless the number of > virtual pages (the second V in V:V:R) exceeds the number of pages in R plus > backing store. > Delaying the conversion of shared to distinct (or at least delaying the reservation of backing store) is one form of over-committing. If we assume that over-committing has been removed, then the fact that the fork succeeded is the promise that both processes have the right to access all of their address space. Any page that is writable needs to have swap space reserved, or you have allowed over committing. The OS can delay actually creating the new pages, and thus save some work, but if you haven't reserved the space for the virtual page, you are allowing an over commit.
-- Richard Damon _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
