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?
> 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...
> 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.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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:27 EST