Re: EXPERIMENTAL: mmap-based memory context / allocator - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: EXPERIMENTAL: mmap-based memory context / allocator
Date
Msg-id 54E0FF4E.4010400@2ndquadrant.com
Whole thread Raw
In response to Re: EXPERIMENTAL: mmap-based memory context / allocator  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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 mmap() is, to my knowledge, noticeably more 
> expensive than sbrk(). Especially with concurrent workloads. Which is
> why the malloc/libc authors chose to use sbrk ...

Any ideas how to simulate such workloads? None of the tests I've done
suggested such issue exists.

> IIRC glibc malloc also batches several allocation into mmap()ed
> areas after some time.

Maybe, there's certainly a lot of such optimizations in libc. But how do
you return memory to system in that case?

-- 
Tomas Vondra                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: EXPERIMENTAL: mmap-based memory context / allocator
Next
From: Tom Lane
Date:
Subject: Re: Allow "snapshot too old" error, to prevent bloat