Messages in this thread | | | From | Jesse Pollard <> | Subject | Re: Virtual vs. physical swap & shared memory forks (clone) | Date | Wed, 29 Mar 2000 19:47:49 -0600 |
| |
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/
| |