On 15.2.2015 21:38, Tom Lane wrote:
> Andres Freund writes:
>> On 2015-02-15 21:07:13 +0100, Tomas Vondra wrote:
>>> On 15.2.2015 20:56, Heikki Linnakangas wrote:
glibc's malloc() also uses mmap() for larger allocations. Precisely
because those allocations can then be handed back to the
Andres Freund writes:
> On 2015-02-15 21:07:13 +0100, Tomas Vondra wrote:
>> On 15.2.2015 20:56, Heikki Linnakangas wrote:
>>> glibc's malloc() also uses mmap() for larger allocations. Precisely
>>> because those allocations can then be handed back to the OS. I don't
>>> think we'd want to use mma
On 15.2.2015 21:13, Andres Freund wrote:
> On 2015-02-15 21:07:13 +0100, Tomas Vondra wrote:
>
>> malloc() does that only for allocations over MAP_THRESHOLD, which
>> is 128kB by default. Vast majority of blocks we allocate are <=
>> 8kB, so mmap() almost never happens.
>
> The problem is that mma
On 2015-02-15 21:07:13 +0100, Tomas Vondra wrote:
> On 15.2.2015 20:56, Heikki Linnakangas wrote:
> > On 02/15/2015 08:57 PM, Tomas Vondra wrote:
> >> One of the wilder ideas (I mentined beer was involved!) was a memory
> >> allocator based on mmap [2], bypassing the libc malloc implementation
> >>
On 15.2.2015 20:56, Heikki Linnakangas wrote:
> On 02/15/2015 08:57 PM, Tomas Vondra wrote:
>> One of the wilder ideas (I mentined beer was involved!) was a memory
>> allocator based on mmap [2], bypassing the libc malloc implementation
>> altogether. mmap() has some nice features (e.g. no issues w
On 02/15/2015 08:57 PM, Tomas Vondra wrote:
One of the wilder ideas (I mentined beer was involved!) was a memory
allocator based on mmap [2], bypassing the libc malloc implementation
altogether. mmap() has some nice features (e.g. no issues with returning
memory back to the kernel, which may be p
