Hello,
On Wed, 9 Feb 2000, Rik van Riel wrote:
> IMHO malloc() should switch to mmap() for the rest :)
>
> > >around 900M if the malloc uses sbrk, but more if it uses mmap.
> > >modern libc's will use mmap for large allocations, since unlike
> > >sbrk, mmap can actually free memory back to the OS.
> >
> > Which version of libc has malloc that uses mmap after 1GB?
>
> None, AFAIK. They use mmap() when you malloc() bigger chunks,
> but they don't use it for smaller chunks when you've run out
> of the first 1GB...
>
> (I'd love to be proven wrong, though...)
I think TASK_UNMAPPED_BASE must be per process issue. Some time
ago I proposed a patch for /proc/sys/kernel/task_unmapped_base sysctl for
2.2.13+ (10-DEC-1999). It is a system setting for x86 users but can help
until malloc() switches to using brk() + mmap(). When malloc can do
this we can set TASK_UNMAPPED_BASE to a small value. Or may be brk()
allocations are preferred. But until then, the task_unmapped_base sysctl
is very useful for big shared regions (DB servers). So, may be it is
useful the process to be able to set this value but for now I don't know
how. Is it possible task_unmapped_base to be per process value? The
default value will be the system setting? /proc/#/task_unmapped_base? Or
may be this is not a good approach? In fact, it can't be controlled
because the shared libs are already mapped to the system value before the
process can change the value. So, may be only the system setting is
useful?
Regards
-- Julian Anastasov <uli@linux.tu-varna.acad.bg>- 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 : Tue Feb 15 2000 - 21:00:14 EST