[olpc-software] welcome to the olpc software mailing list

[Alan Cox]

On Mon, Mar 06, 2006 at 02:08:31PM -0500, Jim Gettys wrote:
> I just need some warning; and we can allocate a very small swap area we
> don't use seriously, so that such memory can be had (at least usually).

Megabytes of memory can suddenely be needed in one sycall when running in OOM
mode, in fact its quite common that this occurs when someone does this

	x = malloc(lots)
	read(fd, x, lots);

because the pages all suddenely get referenced in the read. Also at this
point we are in a syscall that isn't signal interruptible so we have no
way to report back to the offender.

> And it may be a solution where we tell the kernel in advance what
> process to OOM may be reasonable (so you can "kill the right thing"
> without waiting).  In this solution, I somehow need to be able to

That is easy to do but previous attempts didn't really get anywhere, mainly
because a typical OS environment is so complex. The current system has some
heuristics but they are vague at best and mostly designed to avoid shooting
the X server.

> monitor memory consumption (and maybe slow things down) as things get
> tight, to give some processes some warning to save state.

In no-overcommit you know all of this because malloc/mmap/fork and friends
tell you in advance you would over-commit the box.

> Fixing everyone to "do the right think" when malloc fails is nearly
> impossible, particularly in languages like C; what is more, any

If your applications are broken they break. They will die anyway whether
cleanly or not if you don't deal with it. Yes it would be nice to have some
magic armwaving wand that mysteriously made out of memory events just get 
handled but despite much trying nobody has figured out a solution that
actually works yet. It may be easier with a very minimal environment

Alan