On 10/23/2016 05:26 PM, Petr Jelinek wrote:
> On 23/10/16 16:26, Tomas Vondra wrote:
>> On 10/22/2016 08:30 PM, Tomas Vondra wrote:
>> ...
>> Moreover, the slab/gen allocators proposed here seem like a better
>> fit for reorderbuffer, e.g. because they release memory. I haven't
>> looked at sb_alloc too closely, but I think it behaves more like
>> AllocSet in this regard (i.e. keeping the memory indefinitely).
>>
>
> For reorderbuffer, from what I've seen in practice, I'd prefer
> proper freeing to 5% performance gain as I seen walsenders taking GBs
> of memory dues to reoderbuffer allocations that are never properly
> freed.
>
Right.
>
> About your actual patch. I do like both the Slab and the Gen allocators
> and think that we should proceed with them for the moment. You
> definitely need to rename the Gen one (don't ask me to what though) as
> it sounds like "generic" and do some finishing touches but I think it's
> the way to go. I don't see any point in GenSlab anymore.
>
Attached is a v5 of the patch that does this i.e. throws away the
GenSlab allocator and modifies reorderbuffer in two steps.
First (0001) it adds Slab allocator for TXN/Change allocations, and
keeps the local slab cache for TupleBuf allocations (with a separate
AllocSet context).
Then (in 0002) it adds the Gen allocator for TupleBuf, removing the last
bits of the local slab cache.
I do think this version is is as simple as it gets - there's not much
more we could simplify / remove.
The main issue that bugs me is the name of the Gen allocator, but I
don't have a good naming ideas :( The basic characteristics of Gen is
that it does not reuse space released by pfree(), relying on the fact
that the whole block will become free. That should be reflected in the
name somehow, I guess.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services