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

Looks like I have to answer myself here with you guys all busy gitting... I posted two sample programs last week that showed that large application can run out of memory a lot quicker on 2.6 than on 2.4. The reason is that the /proc/*/maps space fragments a lot faster on 2.6 than with 2.4

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

Looks like I have to answer myself here with you guys all busy gitting... I posted two sample programs last week that showed that large application can run out of memory a lot quicker on 2.6 than on 2.4. The reason is that the /proc/*/maps space fragments a lot faster on 2.6 than with 2.4

Re: Leaks in mmap address space: 2.6.11.4

Here is another program that illustrates the problem which this time in C and without using glibc allocation schemes. -- /* run in 32 bit mode on 64Bit kernel, >4GB of RAM is helpful */ #include #include #include #include

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

Here is another program that illustrates the problem which this time in C and without using glibc allocation schemes. -- /* run in 32 bit mode on 64Bit kernel, 4GB of RAM is helpful */ #include stdio.h #include string.h #include