and I couldn't understand why).
> > Newsgroups: comp.unix.sco.programmer
> > Subject: Re: Adding Memory
> > Organization: Microlise Engineering Ltd.
> > X-Newsreader: IBM NewsReader/2 v1.2
> > Davis) writes:
> > >Please explain further- how can not having 2x RAM in swap prevent using
> > >all of RAM? I don't understand....
> > ok, I'll bite... (apologies in advance for a long lecture - I hope I get
> > this all right... :-)
> > Most Unixes (SCO included), think something like this:
> > "I've got X megs of user RAM, and Y megs of swap, so I'll let applications
> > allocate up to X+Y-(possible safety margin) megs of *virtual memory
> > space*".
> > Now this is easy to understand if you think in terms of the memory space
> > that the programs use as actually existing and therefore taking up either
> > RAM or swap.
> > But programs almost always have virtual space allocated that is *not*
> > backed up by RAM or swap; in fact there are three main reasons why:
> > - fork()
> > The parent and child process will share *one* copy of a physical
> > page between *two* *separate* virtual address spaces - until either
> > of them modifies the page;
> > - sbrk(), malloc() etc
> > Newly-allocated memory is created as demand-zero pages - they have
> > no physical existence until they are touched for the first time;
> > - file mapping
> > Program code and static data (and mmap() on files, on Unixes that
> > allow that) are backed by the file itself - they are not read in
> > from the filesystem until they are faulted on, and can be discarded
> > without being paged out if they have not been modified. They
> > therefore may not be taking up any RAM or swap.
> > So a system may have much more virtual memory space in use than can be
> > determined by just looking at the amount of RAM and swap in use.
> > For example, right now, on one of our development boxes:
> > Physical RAM in use: 10416k
> > Swap space in use: 8128k
> > Demand-zero pages: 11952k
> > File-mapped pages: 3756k
> > Copy-on-write pages: 584k
> > ------
> > Virtual space allocated: 34836k
> > Now, if this system had 16M (user) RAM and 20M swap, it might not be
> > showing much paging activity, and 8M swap used out of 20M hardly seems like
> > cause for concern, but since it thinks that the virtual address space is
> > almost exhausted (36M available, 34M allocated) it might start to refuse
> > requests to allocate memory; since it might, after all, be called on to
> > provide RAM or swap to back up all those demand-zero, file-mapped and
> > copy-on-write pages and wants to be able to do so. So fork() might fail,
> > malloc()/sbrk() might fail, and execve() might get SIGKILL signals since
> > these are the main ways in which virtual space is allocated.
> > [In fact, that machine has 32M RAM and 80M swap, so it is running fine.
> > Also, note that the '2x RAM' figure is just a rule of thumb - I tend to
> > use more than that since a few meg of disc space is usually neither here
> > nor there - but reorganising swap space after the fact can get terribly
> > time-consuming...]
> > Warning signs that show you have not enough swap:
> > 1. Programs complain about inability to allocate memory.
> > [Note: this can also be due to exceeding process size limits.]
> > 2. You type a command and get 'Fork failed' or some such error.
> > [Note: this can also be due to exceeding kernel limits.]
> > 3. You type a command and get only the response 'Killed'.
> > [I don't think there are any other causes for this.]
> > In case you were wondering, execve() gets SIGKILL rather than return an
> > error because (one assumes) the virtual memory shortage is not detected
> > until after the old memory image is discarded, so there is no program
> > left to return the error code to...
> > Aside: Some other Unixes, notably AIX, take the opposite view, and say
> > "I'll let the applications allocate as much virtual memory as they want -
> > after all they probably won't access all of it". This approach has the
> > advantage of requiring less swap space, but leaves the system in a bit of
> > a mess when it finds that it has overcommitted the available resources -
> > AIX in these circumstances has a tendency to kill processes to free up
> > memory....
> > ====
by