Re: PATCH: two slab-like memory allocators

On 10/02/2016 12:23 AM, John Gorman wrote:
> I reproduced the quadradic pfree performance problem and verified
> that these patches solved it.
>
> The slab.c data structures and functions contain no quadradic
> components.
>
> I noticed the sizing loop in SlabContextCreate() and came up with a
> similar formula to determine chunksPerBlock that you arrived at.
>

;-)

>> Firstly, I've realized there's an issue when chunkSize gets too
>> large - once it exceeds blockSize, the SlabContextCreate() fails
>> as it's impossible to place a single chunk into the block. In
>> reorderbuffer, this may happen when the tuples (allocated in
>> tup_context) get larger than 8MB, as the context uses
>> SLAB_LARGE_BLOCK_SIZE (which is 8MB).
>>
>> But maybe there's a simpler solution - we may simply cap the
>> chunkSize (in GenSlab) to ALLOC_CHUNK_LIMIT. That's fine, because
>> AllocSet handles those requests in a special way - for example
>> instead of tracking them in freelist, those chunks got freed
>> immediately.
>
> I like this approach because it fixes the performance problems
> with smaller allocations and doesn't change how larger
> allocations are handled.
>

Right.

> In slab.c it looks like a line in the top comments could be clearer.
> Perhaps this is what is meant.
>
> < * (plus alignment), now wasting memory.
>> * (plus alignment), not wasting memory.
>
> In slab.c some lines are over 80 characters could be folded.
>
> It would be nice to give each patch version a unique file name.
>

OK, will fix.

> Nice patch, I enjoyed reading it!
>

;-)

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