Re: 2.6.13 (and before) OOM-Killer activated with plenty of memory available

Sorry about that - brown paper bag time... swappiness was (coming from 2.6.8) still set to 0. As usual setting it back to its default of 60 fixes the problem... Would it be worthwhile to include the swappiness value in the OOM-killer's report? Wolfgang Wolfgang Wander wrote

2.6.13 (and before) OOM-Killer activated with plenty of memory available

Something still seems not right with the OOM handling. The appended program forks 5 children, allocating 1GB each. Running this on a 4GB RAM Intel32 machine that also has 11GB swap available causes an OOM killer activation killing off one of the memory hungry kids. (A 4GB AMD64 machine with 11GB

2.6.13 (and before) OOM-Killer activated with plenty of memory available

Something still seems not right with the OOM handling. The appended program forks 5 children, allocating 1GB each. Running this on a 4GB RAM Intel32 machine that also has 11GB swap available causes an OOM killer activation killing off one of the memory hungry kids. (A 4GB AMD64 machine with 11GB

Re: 2.6.13 (and before) OOM-Killer activated with plenty of memory available

Sorry about that - brown paper bag time... swappiness was (coming from 2.6.8) still set to 0. As usual setting it back to its default of 60 fixes the problem... Would it be worthwhile to include the swappiness value in the OOM-killer's report? Wolfgang Wolfgang Wander wrote

Avoiding maps fragmentation Was: Leaks in mmap address space: 2.6.11.4

} - start_addr = addr = mm->free_area_cache; + start_addr = addr = TASK_UNMAPPED_BASE; /* mm->free_area_cache; */ full_search: for (vma = find_vma(mm, addr); ; vma = vma->vm_next) { Wolfgang Wander writes: > Here is another program that illustrates the problem wh

Avoiding maps fragmentation Was: Leaks in mmap address space: 2.6.11.4

-free_area_cache; + start_addr = addr = TASK_UNMAPPED_BASE; /* mm-free_area_cache; */ full_search: for (vma = find_vma(mm, addr); ; vma = vma-vm_next) { Wolfgang Wander writes: Here is another program that illustrates the problem which this time in C and without using glibc

Re: Leaks in mmap address space: 2.6.11.4

!= EOF ) putchar(c); fclose(f); return 0; } ------ Wolfgang Wander writes: > Hi, > > we are running some pretty large applications in 32bit mode on 64bit > AMD kernels (8GB Ram, Dual AMD64 CPUs, SMP). Kernel is 2.6.11.4 or > 2.4.21. > > Some

Leaks in mmap address space: 2.6.11.4

Hi, we are running some pretty large applications in 32bit mode on 64bit AMD kernels (8GB Ram, Dual AMD64 CPUs, SMP). Kernel is 2.6.11.4 or 2.4.21. Some of these applications run consistently out of memory but only on 2.6 machines. In fact large memory allocations that libc answers

Leaks in mmap address space: 2.6.11.4

Hi, we are running some pretty large applications in 32bit mode on 64bit AMD kernels (8GB Ram, Dual AMD64 CPUs, SMP). Kernel is 2.6.11.4 or 2.4.21. Some of these applications run consistently out of memory but only on 2.6 machines. In fact large memory allocations that libc answers

Re: Leaks in mmap address space: 2.6.11.4

; } -- Wolfgang Wander writes: Hi, we are running some pretty large applications in 32bit mode on 64bit AMD kernels (8GB Ram, Dual AMD64 CPUs, SMP). Kernel is 2.6.11.4 or 2.4.21. Some of these applications run consistently out of memory but only