On Monday, 9 December, 2019 20:02, Richard Damon <rich...@damon-family.org> wrote:
>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. Yes, you are correct. In order to not allow overcommit all the writeable pages would have to be committed storage, even if they are presently mapped to read from an already existing virtual page (as in CoW). -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
