Re: EXPERIMENTAL: mmap-based memory context / allocator
От | Tomas Vondra |
---|---|
Тема | Re: EXPERIMENTAL: mmap-based memory context / allocator |
Дата | |
Msg-id | 54E0FC71.9000701@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: EXPERIMENTAL: mmap-based memory context / allocator (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: EXPERIMENTAL: mmap-based memory context / allocator
|
Список | 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
В списке pgsql-hackers по дате отправления: