Messages in this thread | | | From | (david parsons) | Subject | Re: Avoiding OOM on overcommit...? | Date | 27 Mar 2000 15:59:02 -0800 |
| |
In article <linux.kernel.200003270740.AAA00882@vindaloo.ras.ucalgary.ca>, Richard Gooch <rgooch@ras.ucalgary.ca> wrote: >Linda Walsh writes: >> Richard Gooch wrote: >> > Each of these options is flawed: >> > >> > 1&2) you have to do this for all processes > >[bugger, you've removed the context] > >> You have to assign process ID's, memory mappings, etc to every >> process. So what's your point? Having a default guaranteed stack > >No, *I* don't have to allocate PIDs. The kernel does that for me. > >To avoid overcommit, I have to limit the stacksize for all >processes.
No you don't; just follow the same logic that exists for a stack overrunning the stack limit: out of limit ::= program fall down go boom. For an assurance that the program won't go down and fall boom for that reason, you can go out of your way to preallocate.
____ david parsons \bi/ The only place where overcommit is really really useful \/ is the emacs editing a 100mb file case, and maybe vfork + page ownership would be a better solution there.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |