| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | 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:07:13 |
| Message-ID: | 54E0FC71.9000701@2ndquadrant.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 with returning
>> memory back to the kernel, which may be problem with sbrk). So I hacked
>> a bit and switched the AllocSet implementation to mmap().
>
> 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 mmap() for small allocations either. Let's not
> re-invent malloc()..
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.
At least that's my understanding, I may be wrong of course.
>
> - Heikki
>
--
Tomas Vondra http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-02-15 20:13:24 | Re: EXPERIMENTAL: mmap-based memory context / allocator |
| Previous Message | Heikki Linnakangas | 2015-02-15 19:56:51 | Re: EXPERIMENTAL: mmap-based memory context / allocator |