"Richard B. Johnson" wrote:
> Even if the perfect operating system kept some virtual RAM for
> 'root' to log-in. It has no idea of what programs root would
> want to execute. Eventually, it will fail with an out-of memory
> condition.
--- Having no idea of what programs root would execute doesn't mean you can't reserve sufficient memory for a shell, a ps and a kill. But if my machine runs out of processes and I can't log in -- I have little choice but to hit the RESET button.> > Therefore all known Unix Operating Systems allow the use of > 'currently unused' virtual RAM. This RAM may have been allocated, but > it has not been touched yet. The tasks that have allocated it will > not even know that it was 'borrowed'. This is the nature of > "over commit". --- Not all unix systems, however, allow it by default. Some have realized that allocating memory with no "assurance" lowers the overall integrity/security of the system. Some require that an administrator explicitly allow the unsafe behavior after they have learned about the implications.
By allowing 'overcommit', you end up in a situation where now your 90M process touches the last of its memory -- and it isn't there, so.... it SEGFAULT's because the memory mapper can't the address to a physical \ object?
If you allow overcommit, you can have *either* the SEGFAULT behavior *or* the no-mem/locked out (process touches everything up front). If you disallow overcommit, you reduce the possible behaviors to 1. The problem is that suppose the process allocates it's memory -- with the 'overcommit' you have a system where it is hard to predict *what* will fail. Will it be a system process? A deamon? It's a low-integrity system because you can't figure out the behavior of failure in advance.
David's killing demon is fine for a user-space/level solution, but the kernel should default to the high-integrity option.
If a distribution vendor wants to ship with 'virtual memory' turned on, they could have an added entrying in the fstab:
none vswap vswap size=1G 0 0
(default swap-prio for vswap is none -- lower than any other swap space).
This way you could allow someone to create the same behavior as now, but by explicit choice by the sysadmin.
-linda
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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:16 EST