On Thu, 30 Mar 2000, Horst von Brand wrote:
>Jesse Pollard <pollard@cats-chateau.net> said:
>> 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().
>
>What does this handler do? Get more stack space, or terminate the program?
>Page the sysadmin?
Any of what you suggested. Normally I would expect it to get more stack space.
If it cant get any then it may choose to terminate, saving state; terminate
without saving state; or page the sysadmin if that is what was deemed necessary.
>
>> 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.
>
>I have a radical idea: Let's let everybody use as much stack as they
>need. If the system runs out of memory, something has to give up memory
>anyway, and we then select a memory hog and kill it. Won't be used much, as
>a reasonably speced system won't get near this in its entire life.
>Oops... that is what we have today with Rik's patch...
Lets have a more radical idea - IMPOSE USER QUOTAS and prevent the problem.
What you are suggesting is unreliability, and insecurity.
>> 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 is what the kernel does today, without involving a sysadmin. And if
>there is no more memory, no fancy scheme will get you around that fact
>anyway. This makes the problem _worse_ by stealing memory from processes
>that need it just in case this process might want to use it in the far future.
1. What is provided is a way to terminate gracefully, possibly even saving
state information for a restart later.
2. Can't make it any worse. That's not possible.
-------------------------------------------------------------------------
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:28 EST