"A month of sundays ago David Whysong wrote:"
> Again, this isn't very meaningful. Any non-deterministic behavior isn't a
> result of overcommitment, it's due to the fact that the kernel hasn't been
> informed of what to do when OOM. That can be fixed without removing memory
> overcommitment. Just implement quotas, or alternately task priorities and
> have the kernel kill the lowest priority tasks first. After all, by the
> time you start killing tasks on an overcommitted system, you would have
> been killing tasks long before without overcommit...
I'd suggest that killing the task with shortest ancestry (to login) is
fair. It's the latecomer to the feast.
BTW, didn't gnu wrap malloc in a memory-walk, to force the kernel to
commit memory at the time it was asked for? Is that calloc nowadays?
If so, then nobody can make complaints based on the behavior of malloc
as they can correct it themselves by using the wrapper. It'll just be
slower than plain malloc, requiring one memory read/write per 4k
allocated.
In conjunction with "killing the latecomer" if memory is right out,
that seems almost fair. No process will be surprised by not having
memory it malloced, unless it chose to let itself be surprised (by not
using the malloc wrapper), and then who asked first counts.
That leaves the stack: processes can still run out of stack they
thought they had. One may wish to reduce the initial stack space to 128K,
and require processes to explicitly call sbrk to increase it. Ecch.
I'd hate that. But it would guarrantee about 128 processes on a 16MB
machine.
One could also make sbrk automatic ... when the current allocation
is exceeded, call sbrk to double it. If we fail, signal the process to
die.
A special signal seems appropriate! Not sigsegv, certainly.
Peter
-
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 : Fri Mar 31 2000 - 21:00:17 EST