Re: Overcommitable memory??

From: Olaf Weber (olaf@infovore.xs4all.nl)
Date: Thu Mar 23 2000 - 05:15:56 EST


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/



This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:38 EST