Linda Walsh <law@sgi.com> said:
> "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.
And if root logs in to play a game of nethack, what then?
> > 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.
OK, how about telling us among Unices (or similar) which ones allow
overcommit or not be set. What is the default? How do they usually run?
Which ones don't allow overcommit at all? Please keep to recent versions; a
(rough) estimate of market share would be nice too.
> 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?
By not overcommiting, that 90Mb process either doesn't get off the ground,
or nothing else can run at all. Even if the *potentially* 90Mb process
isn't using much memory ATM. And if the 90Mb process asks for memory a bit
at a time, it can get killed for trying to get memory which others have
reserved because they might use it, like 8Mb for stack for ls(1) asked to
see if file foo exists.
> 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.
It isn't harder to predict than in the no overcommit case: Some process
gets killed, the one that happens to ask for memory when the system can't
commit more (essentially at random), or (much, much later in the life of
whatever got the system OOM) some probable culprit (Rik's patch).
> David's killing demon is fine for a user-space/level solution, but
> the kernel should default to the high-integrity option.
Nonsense. Few people are prepared to shell out 5 times the needed RAM +
swap just in case everybody decides unanimously to change all pages at
their reach. True, there are applications where this is required, but they
are far in between.
[...]
> This way you could allow someone to create the same behavior as
> now, but by explicit choice by the sysadmin.
Please, yet again: OOM is an extreme situation, if you let your system go
that far with any frequency then _you_ are broken, or the system is
hopelessly underspeced. If you add non-overcommit to a overworked machine
you get very predictable behaviour, i.e., none at all. Coding up any of the
wonderful "easy, non overcommiting schemes" is _hard_ and would need
extensive changes in the kernel (the kernel _does_ use memory, and such use
is not bounded today). This would undobtedly cost quite a bit in
performance, together with the performance loss of allocating swap space
for nothing. Getting that accounting 100% right (and keeping it that way!)
isn't easy either, so this is a huge project.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- 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