From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <140e7ec30709041037wcb4b60bldf20a9d3c52e4e5a@mail.gmail.com> Date: Wed, 5 Sep 2007 01:37:03 +0800 From: sqweek To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] plan 9 overcommits memory? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070902212734.DF2D31E8C26@holo.morphisms.net> Topicbox-Message-UUID: b7b1c870-ead2-11e9-9d60-3106f5b1d025 On 9/3/07, erik quanstrom wrote: > if((p = malloc(Size)) == 0) > /* malloc recovery code */ > /* why bother? the kernel could be lying to us anyway. */ Having run into issues writing codes with large memory footprints on linux (which also overcommits [by default]), erik's comment here is close to my heart. Indeed, what's the point of a malloc interface that returns 0 when in practice the kernel kills your process before that happens? It strikes me as irresponsible to advertise an interface you won't/can't honour. This is certainly my biggest problem with overcommitting. Well, that and the non determinism, but it's not clear to me that's avoidable when memory is exhausted. geoff@plan9.bell-labs.com wrote: > The big exception is stack growth. The > kernel automatically extends a process's stack segment as needed. OK, so the stack takes precedence over heap allocations. What if it was the other way around? Instead of stealing pages that process Y has malloc'd but not yet touched to grow the stack of process X, kill process X because there's not enough memory left to grow the stack... Mmmm. I don't think I helped anything. On the surface it looks like I'm honouring the malloc request, but there's probably a fair chance X == Y and the non-determinism really is the problem. Well, I guess the next question is: Is malloc's interface sufficient/practical? -sqweek