Subject: Re: PATCH: two slab-like memory allocators
To: John Gorman <johngorman2@gmail.com>
References: <d15dff83-0b37-28ed-0809-95a5cc7292ad@2ndquadrant.com>
 <c5653004-fe91-5a13-409c-db9f34642b0c@2ndquadrant.com>
 <68b837a3-ce55-f9a2-f685-9eafac536f21@2ndquadrant.com>
 <885540a7-ac72-5a21-6dae-a4d5b50672da@2ndquadrant.com>
 <03110c11-ea72-7b4d-027d-6f19eb300b2a@2ndquadrant.com>
 <CALkS6B9W0xHS25OOq2sWhUWtS79XuPiiAOFpsh6F8v56uAvy_Q@mail.gmail.com>
Cc: Petr Jelinek <petr@2ndquadrant.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <9b74fc50-940f-8ca5-36e4-32010fcde2c4@2ndquadrant.com>
Date: Sun, 2 Oct 2016 02:36:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101
 Thunderbird/46.0a2
MIME-Version: 1.0
In-Reply-To: 
 <CALkS6B9W0xHS25OOq2sWhUWtS79XuPiiAOFpsh6F8v56uAvy_Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers