2.4 kernel series and the oom_killer and /proc/sys/vm/overcommit_memory

2.4 kernel series and the oom_killer and /proc/sys/vm/overcommit_memory

[Marc-Christian Petersen]

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 www.keyserver.net. Encrypted e-mail preferred.

Re: 2.4 kernel series and the oom_killer and /proc/sys/vm/overcommit_memory

[Robert Love]

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

Re: 2.4 kernel series and the oom_killer and /proc/sys/vm/overcommit_memory

[Alan Cox]

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

Re: 2.4 kernel series and the oom_killer and /proc/sys/vm/overcommit_memory

[Daniel Phillips]

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

Re: 2.4 kernel series and the oom_killer and /proc/sys/vm/overcommit_memory

[Rik van Riel]

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/

Re: 2.4 kernel series and the oom_killer and /proc/sys/vm/overcommit_memory

[Daniel Phillips]

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