2009/9/2 Andrés Domínguez <andres...@gmail.com>: > 2009/9/2 erik quanstrom <quans...@quanstro.net>: >> >> aside: from the overcommit vm discussion. >> in http://9fans.net/archive/2000/06/634 rob >> says that plan 9 doesn't overcommit vm. >> what's the history here? > > Exactly two years ago you started a thread about > memory overcommit. If I remember correctly, plan9 > overcommits vm. Few weeks later the Go program > from gorka crashed while allocating the stack, maybe > an overcommiting check was added, probably gorka > knows.
No checks have been added. I started a rather active thread about this a few months ago in attempt to figure out a way to `protect' from this behavior starving the kernel of memory and thus panicking. I'll leave it up to Elly to find some way to actually exploit this :). The problem ended up being that I'd have to rework a lot of the slab allocator, or do checks on every memory allocation, and I didn't want to do that. More detailed info for those who care: Lemma: In order to avoid overcommitting, we must impose limits on how much memory may, in fact, be allocated. To make the implementation provable, you must be able to assert that memory always comes from the same spot, and you thus have a single path to follow into allocation. Memory limits must be enforced based on real hardware in the system. The issue here is that some slabs will always fill up disproportionately to others. Thus, whichever limit you impose, slabs must be growable. Thus: - Systemic limits require you to be able to migrate pages between zones. - Per-zone memory limits are silly because you have to be able to migrate pages between zones, - Per-process and per-user memory limits are silly, though easier to implement, because they add too much overhead to allocations and frees. Basically, it boils down to: If you want to implement this effectively, the slab allocator needs to be reworked so that memory zones can `steal' pages from other zones. If this is a real issue, I'm happy to go take another stab at it: I stopped working on it last time because it seemed most people found it a non-issue. --dho > Andrés > >
