Re: Memory management in Kernel 2.4.x

[Andreas Hartmann <andihartmann@freenet.de>]

Alan Cox wrote:

> On Mon, 2002-05-27 at 10:40, Andreas Hartmann wrote:
>> Unfortunately, the memory management of kernel 2.4.x didn't get better
>> until today. It is very easy to make a machine dead. Take the following
>> script:
>> 
>> 
http://groups.google.com/groups?q=malloc+bestie&hl=de&lr=&selm=slrn8aiglm.tqd.pfk@c.zeiss.de&rnum=2
>> 
>> 
>> The result with kernel 2.4.19pre8ac4:
>> 
>> May 27 11:04:21 athlon kernel: Out of Memory: Killed process 763 (knode).
> 
> This appears to be correct behaviour. You allocated astronomical amounts
> of memory and had memory overcommit enabled so it broke. Thats
> configurable and you can if you wish disable overcommit in the -ac
> kernel by setting /proc/sys/vm/overcommit_memory to 2 (thats not
> supported by the base 2.4 kernels yet). If you can make it OOM in that
> mode then I am interested indeed.

I tested it and got in the result the same problem. Well, no processes got 
killed by the kernel and the virtual memory didn't grow up to the end (as 
far as I could see it).
But every (other, regular) process crashed when it wanted to have some 
memory because it didn't get the memory. Or I wasn't able to start any new 
process - I even couldn't do a logon via ssh or a local login at the 
console.


May 27 13:37:12 athlon login: PAM unable to 
dlopen(/lib/security/pam_pwdb.so)
May 27 13:37:12 athlon login: PAM [dlerror: libpwdb.so.0: failed to map 
segment from shared object: Cannot allocate memory]
May 27 13:37:12 athlon login: PAM adding faulty module: 
/lib/security/pam_pwdb.so
May 27 13:37:13 athlon out of memory [198out of me]
May 27 13:37:15 athlon login: PAM unable to 
dlopen(/lib/security/pam_pwdb.so)
May 27 13:37:15 athlon login: PAM [dlerror: libpwdb.so.0: failed to map 
segment from shared object: Cannot allocate memory]
May 27 13:37:15 athlon login: PAM adding faulty module: 
/lib/security/pam_pwdb.so
May 27 13:37:15 athlon out of memory [2617out of m]
May 27 13:37:15 athlon last message repeated 29 times
May 27 13:37:23 athlon login: PAM unable to 
dlopen(/lib/security/pam_pwdb.so)
May 27 13:37:23 athlon login: PAM [dlerror: libpwdb.so.0: failed to map 
segment from shared object: Cannot allocate memory]
May 27 13:37:23 athlon login: PAM adding faulty module: 
/lib/security/pam_pwdb.so
May 27 13:37:23 athlon out of memory [2620out of m]
May 27 13:37:23 athlon last message repeated 29 times
May 27 13:37:27 athlon login: PAM unable to 
dlopen(/lib/security/pam_pwdb.so)
May 27 13:37:27 athlon login: PAM [dlerror: libpwdb.so.0: failed to map 
segment from shared object: Cannot allocate memory]
May 27 13:37:27 athlon login: PAM adding faulty module: 
/lib/security/pam_pwdb.so
May 27 13:37:27 athlon out of memory [199out of me]
May 27 13:39:36 athlon login: PAM unable to 
dlopen(/lib/security/pam_pwdb.so)
May 27 13:39:36 athlon login: PAM [dlerror: libpwdb.so.0: failed to map 
segment from shared object: Cannot allocate memory]
May 27 13:39:36 athlon login: PAM adding faulty module: 
/lib/security/pam_pwdb.so
May 27 13:39:36 athlon out of memory [2629out of m]
May 27 13:39:36 athlon last message repeated 29 times
May 27 13:42:01 athlon sshd[124]: error: fork: Cannot allocate memory

All in all, the overcommitment - option seems to work fine (the machine 
responded well :-)), but it should restrict just the process which leads 
the machine to death. All other processes should be as free as before.

> The rsync one is more interesting, it could be something doing huge
> amounts of memory allocations it could also be excessive kernel usage or
> wrong OOM semantics somewhere.

rsync allocates all of the memory the machine has (256 MB RAM, 128 MB swap). 
When this occures, processes get killed like described in the posting 
before. The machine doesn't respond as long as the rsync - process isn't 
killed, because it fetches all the memory which gets free after a process 
has been killed.


Regards,
Andreas Hartmann