From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: EXPERIMENTAL: mmap-based memory context / allocator |
Date: | 2015-02-15 20:19:26 |
Message-ID: | 54E0FF4E.4010400@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-02-15 20:27:00 | Re: Allow "snapshot too old" error, to prevent bloat |
Previous Message | Andres Freund | 2015-02-15 20:13:24 | Re: EXPERIMENTAL: mmap-based memory context / allocator |