What are the advantages and disadvantages if we always use mmap to allocate memory instead of malloc ?

[孙世龙 sunshilong]

>What mmap and sbreak are good for
>is to make available *big* chunks of memory, which are dealt out
>in small chunks by some library via malloc and friends.

As per the Linux Programmer Manual, which says:
For  allocations  greater than or equal to the limit specified (in bytes)
by M_MMAP_THRESHOLD that can't be satisfied from the free list,
the memory-allocation functions employ mmap(2) instead of
increasing the program break using sbrk(2).

I can draw the conclusion that malloc(3) may invoke mmap(2) when
allocating a huge block memory.

So I think there may be something wrong with your conclusion(i.e.
mmap calls malloc to allocate a big block).

What do you think about it? Am I missing something?
Thank you for your attention to this matter.

On Wed, Aug 12, 2020 at 4:42 PM <tomas@tuxteam.de> wrote:
>
> On Wed, Aug 12, 2020 at 09:58:10AM +0200, Florian Weimer wrote:
> > * 孙世龙 sunshilong via Libc-help:
> >
> > > What are the advantages and disadvantages if we always use mmap to
> > > allocate memory instead of malloc.
> >
> > On Linux, the advantage of using mmap is that the kernel might find
> > usable address space in more cases.  There is also no problem when
> > multiple allocators each call mmap indepedently.  With sbrk, that
> > would be a problem.  As long as address space is available, sbrk
> > maintains a single memory mapping, which can be more efficient.
>
> Talking from the peanut gallery: what Florian is saying is that mmap
> can replace sbreak -- not malloc. What mmap and sbreak are good for
> is to make available *big* chunks of memory, which are dealt out
> in small chunks by some library via malloc and friends.
>
> I had the impression this wasn't clear.
>
> Cheers
>  - t