Hi there,
I just have one question.
If I understand it correct, /proc/sys/vm/overcommit_memory controls if there
is "1" always enough memory and if "0" every program call checks if there is
enough memory.
I just tried to open up much Xterms until my RAM + SWAP is full. The system is
up and response is slowly for ~ 5 minutes, doing whatever, swapping or kinda
that. This was tested with overcommit_memory == 0 ... With 2.4.19, the
oom_killer comes NOT in action, after the 5 minutes the system is dead. With
2.4.18's oom_killer there are program kills at random.
My question now: Why isn't it possible, if overcommit_memory is 0, to really
check if there is enough memory or not, and if NOT just to display a message
like "Not enough memory for execution. Aborted" ?
TIA!
--
Kind regards
Marc-Christian Petersen
http://sourceforge.net/projects/wolk
PGP/GnuPG Key: 1024D/569DE2E3DB441A16
Fingerprint: 3469 0CF8 CA7E 0042 7824 080A 569D E2E3 DB44 1A16
Key available at http://www.keyserver.net. Encrypted e-mail preferred.
On Thu, 2002-08-22 at 11:19, Marc-Christian Petersen wrote:
> My question now: Why isn't it possible, if overcommit_memory is 0, to really
> check if there is enough memory or not, and if NOT just to display a message
> like "Not enough memory for execution. Aborted" ?
Because the overcommit checks in 2.4 stock are heuristic in nature -
they simple compare an estimate of committed memory against what you are
trying to allocate.
In 2.5 and 2.4-ac we have strict overcommit which couple accurate
accounting of the committed address space with stricter rules to prevent
overcommit.
Robert Love
On Thu, 2002-08-22 at 16:19, Marc-Christian Petersen wrote:
> If I understand it correct, /proc/sys/vm/overcommit_memory controls if there
> is "1" always enough memory and if "0" every program call checks if there is
> enough memory.
No
0 is a heuristic overcommit
1 is "anything goes"
and with a -ac kernel
2 is a proper overcommit manager
3 is a totally paranoid one that will require everything in ram can be
dumped to swap or paged back from backing store
On Thursday 22 August 2002 19:32, Alan Cox wrote:
> 3 is a totally paranoid [overcommit policy] that will require everything in
> ram can be dumped to swap or paged back from backing store
How do you handle the situation where you have a lot of shared memory in a
half-paged-out state, so that each shared page consumes both ram and swap?
--
Daniel
On Sat, 24 Aug 2002, Daniel Phillips wrote:
> On Thursday 22 August 2002 19:32, Alan Cox wrote:
> > 3 is a totally paranoid [overcommit policy] that will require everything in
> > ram can be dumped to swap or paged back from backing store
>
> How do you handle the situation where you have a lot of shared memory in a
> half-paged-out state, so that each shared page consumes both ram and swap?
That will work fine with 'totally paranoid' mode. There is always
enough swap space to hold _all_ pages, so everything will just
continue to work.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On Saturday 24 August 2002 05:46, Rik van Riel wrote:
> On Sat, 24 Aug 2002, Daniel Phillips wrote:
> > On Thursday 22 August 2002 19:32, Alan Cox wrote:
> > > 3 is a totally paranoid [overcommit policy] that will require everything in
> > > ram can be dumped to swap or paged back from backing store
> >
> > How do you handle the situation where you have a lot of shared memory in a
> > half-paged-out state, so that each shared page consumes both ram and swap?
>
> That will work fine with 'totally paranoid' mode. There is always
> enough swap space to hold _all_ pages, so everything will just
> continue to work.
Apparently, maximum available memory is limited to
physical memory + (swap - physical memory) = just swap
in this case, and if swap is smaller than (the potentially swappable portion
of) physical memory you might as well just turn it off.
--
Daniel