Re: slab allocator performance issues

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: slab allocator performance issues
Дата
Msg-id 20210718010600.fat2f5j4gvqig56j@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: slab allocator performance issues  (Andres Freund <andres@anarazel.de>)
Ответы Re: slab allocator performance issues
Список pgsql-hackers
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...

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: slab allocator performance issues
Следующее
От: Michael Paquier
Дата:
Сообщение: Failure with 004_logrotate in prairiedog