Messages in this thread | | | Subject | Re: Overcommitable memory?? | From | Olaf Weber <> | Date | 23 Mar 2000 11:15:56 +0100 |
| |
Marco Colombo writes:
[On coping with system OOM of an overcommitting system in a program.]
> Do you pass arguments in registers, instead of stack?
> Are you sure the variable 'bailout_addr' does not belong to a page > that has been paged-out, at the time the signal-handler is invoked?
> If your application just exits, you don't need to catch the signal, > you don't need the signal at all.
> If is tries to do something useful, it has to be sure it won't cause > any other page-fault, or will make things just worse.
> Unless the kernel starts sending signals when swap utilization exceeds > 75%.
It wouldn't need to do so when swap is at 75%, but it does need to begin taking action when there are still some pages of memory or swap available, so that some swapping can be done.
Then things depend on the robustness of the memory management in general. For example, it helps if a process is guaranteed to have a certain working set when it is running. Then you can kick out unmodified pages from its text segments to make room for other text pages, because the binary is the backing store in that case.
It has already been pointed out that a stack for signal handling can be preallocated (and locked into memory).
There are other options than just killing processes provided the system makes at least some attempt to be robust when running out of virtual memory.
[...]
-- Olaf Weber
Do not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety.
- 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/
| |