Messages in this thread | | | Date | Sun, 26 Mar 2000 18:35:10 -0800 (PST) | From | David Whysong <> | Subject | Re: Avoiding OOM on overcommit...? |
| |
On Sun, 26 Mar 2000, Linda Walsh wrote: >Richard Gooch wrote: >> I still haven't seen a description of how we handle stack exhaustion >>properly. All we can do there is kill the offending process. > > Naw....we have lots of options. The first and best 1) A gram of >prevention is worth a kilogram of cure. If the developer or user knows that >a given program uses alot of stack space, then an option in 'ld' to specify >size of stack to commit,
This does not work in general. In order to protect any given process, you have to fix the stack allocation of ALL processes, not just the one you care about. And what do you do in the case of recursion, when you don't know in advance the number of times you will recurse?
This is also another example of solving the problem by defining all current software to be broken.
>or 2) User says "runprog -stacksize=1M <programname>" or some such >option -- and 1M of stack space is committed/reserved before when >loading the program.
Same problem as before...
> 3) We use a signal -- I sorta like overuse of SIGSTKFLT, but there may > be reasons not to use it. If in default, program dies as from a SEGV,
Why not just keep overcommit, have malloc() always succeed, and then use a signal anyway when memory is low? Unfortunately Linux doesn't have any spare signals lying around -- especially if you use threads (linuxthreads uses SIGUSR1 and SIGUSR2).
4) if ignored, program is put to sleep waiting on free pages.
This leads to a deadlock.
> Not to sound repetitious, but why is lack of memory (a resource as >David puts it) so different from #processes, #open files/system /process, >out of diskspace on a write call, unable to acquire a 'lock' resource...
Read my previous mail for some reasons.
Dave
David Whysong dwhysong@physics.ucsb.edu Astrophysics graduate student University of California, Santa Barbara My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6 D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91
- 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/
| |