Hi,
> please excuse me, maybe this is not a kernel-related question but it
> could be (my observations were made in userland).
I don't think it's related to the kernel. If you continue to see such
problems please use `glibcbug'.
> when multiple (linux-)threads are calling lots of malloc()/free(), it
> often happens that the malloc() call returns NULL although I have enough
> memory left. This happens with Linux 2.2.14 SMP on Alpha and on Intel.
Please try glibc-2.1.3. glibc-2.1.2 did have a problem somewhat like
that, but only for the very first allocations, if they were larger
than 128k. Repeated attempts to malloc() from concurrent threads
would eventually succeed.
> It does not happen on 2.2.14UP or on Tru64 SMP (by the way: Tru64 is
> much much faster for the same problem: 20 threads calling
> malloc(1024*1024)/free())
I suspect Tru64 doesn't repeatedly map and unmap 1MB but keeps handing
out the same 1MB chunk? glibc by default is more space-conserving,
but you can get the same effect by setting MALLOC_MMAP_MAX_=0 and
MALLOC_TRIM_THRESHOLD_=100000000 in the environment.
Regards,
Wolfram.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:20 EST