From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Tomas Vondra <tv@fuzzy.cz>
Subject: Re: slab allocator performance issues
Date: Sun, 18 Jul 2021 19:23:31 +0200
Message-ID: <37dc9b41-dd75-251d-a77e-16c72c794b00@enterprisedb.com> (raw)
In-Reply-To: <20210718010600.fat2f5j4gvqig56j@alap3.anarazel.de>
References: <20210717194333.mr5io3zup3kxahfm@alap3.anarazel.de>
<c3bf99d3-0dec-828e-e3b5-ed2d2922bdd8@enterprisedb.com>
<20210717211405.3ocp2rpxlnozg3tq@alap3.anarazel.de>
<02ff3ced-3212-aea1-c7a0-4829f43e58d2@enterprisedb.com>
<20210717231019.blfhyqniu6jed3ym@alap3.anarazel.de>
<20210718010600.fat2f5j4gvqig56j@alap3.anarazel.de>
On 7/18/21 3:06 AM, Andres Freund wrote:
> Hi,
>
> On 2021-07-17 16:10:19 -0700, Andres Freund wrote:
>> Instead of populating a linked list with all chunks upon creation of a block -
>> which requires touching a fair bit of memory - keep a per-block pointer (or an
>> offset) into "unused" area of the block. When allocating from the block and
>> theres still "unused" memory left, use that, instead of bothering with the
>> freelist.
>>
>> I tried that, and it nearly got slab up to the allocation/freeing performance
>> of aset.c (while winning after allocation, due to the higher memory density).
>
> Combining that with limiting the number of freelists, and some
> microoptimizations, allocation performance is now on par.
>
> Freeing still seems to be a tad slower, mostly because SlabFree()
> practically is immediately stalled on fetching the block, whereas
> AllocSetFree() can happily speculate ahead and do work like computing
> the freelist index. And then aset only needs to access memory inside the
> context - which is much more likely to be in cache than a freelist
> inside a block (there are many more).
>
> But that's ok, I think. It's close and it's only a small share of the
> overall runtime of my workload...
>
Sounds great! Thanks for investigating this and for the improvements.
It might be good to do some experiments to see how the changes affect
memory consumption for practical workloads. I'm willing to spend soem
time on that, if needed.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@enterprisedb.com, andres@anarazel.de, tv@fuzzy.cz
Subject: Re: slab allocator performance issues
In-Reply-To: <37dc9b41-dd75-251d-a77e-16c72c794b00@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox