Messages in this thread | | | Subject | Re: Virtual vs. physical swap & shared memory forks (clone) | Date | Thu, 30 Mar 2000 08:29:24 -0400 | From | Horst von Brand <> |
| |
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/
| |