From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] plan 9 overcommits memory? From: erik quanstrom Date: Sun, 2 Sep 2007 20:43:45 -0400 In-Reply-To: <20070902212734.DF2D31E8C26@holo.morphisms.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: b45eec2a-ead2-11e9-9d60-3106f5b1d025 > the problem is not really as easy as it might seem at first. > malloc just moves the brk, but the backing pages don't get > allocated until the pages are accessed (during memset). > i'm just suprised that plan 9 overcommits. this makes this code nonsensical from user space if((p = malloc(Size)) == 0) /* malloc recovery code */ /* why bother? the kernel could be lying to us anyway. */ also, by default plan 9 assumes that there are 16 MB of memory more than actually exist. i would think with today's large memories typically, one would want to assume the worst and underestimate the amount of memory required so malloc would fail rather than getting a page fault later. > you could argue for some kind of accounting that would > ensure pages were available, but this could only be > terribly pessimistic, especially in the case of stacks > and fork. how pessimistic would this be? i'll gladly trade a substantial chunk of memory for failure on allocation rather than failure on access. - erik