On Sat, 25 Mar 2000, Richard Gooch wrote:
>Linda Walsh writes:
>> > Removing overcommit might make malloc() return null, but that's only one
>> > of a host of ways to allocate memory. The other methods don't have a
>> > return value. So arguing that "overcommit is bad, because it breaks the
>> > malloc() return value" is pointless.
>>
>> What other methods? calloc - ENOMEM, open <object>, ENOMEM, fork:
>> ENOMEM. Etc. All what you would expect if there was NOMEM.
>
>Stack "allocation". No error code available.
This is the one place where a stack warning signal would be usefull - when
the last page of stack is entered, a signal can be sent, and handled.
This has been done on other unix systems, and can be completely hidden from
the user by installing the signal handler before calling the function main().
To reduce the number of faults generated, I would suggest
a) an initial allocation (determined by sysadmin) to be large enough to cover
50-75% of the programs. This would allow the standard utilities to never
see a fault. If the sysadm preferred, the size could be trimmed.
b) when the stack is extended (amount determined by sysadmin) it is extended by
enough to increase the time to the next page fault.
This might be done by modifing (I know, this might break something) brk to
have two parameters - a segment end, and a stack/heap flag. If it knew the
heap is being extended, then the operation is the same as current.
If the flag is stack, then it extends the user stack.
In either case, if the extension fails, then the user process knows it
before a catastrophic abort occurs.
In the non-overcommited operation the process knows it is reaching the
users virtual limit.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net
Any opinions expressed are solely my own.
-
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:26 EST