Re: SlabCheck leaks memory into TopMemoryContext

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: SlabCheck leaks memory into TopMemoryContext
Дата
Msg-id 20200116061732.vvpyexenaortpu5y@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: SlabCheck leaks memory into TopMemoryContext  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: SlabCheck leaks memory into TopMemoryContext
Список pgsql-hackers
Hi,

On 2020-01-16 00:09:53 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I just noticed that having a slab context around in an assertion build
> > leads to performance degrading and memory usage going up. A bit of
> > poking revealed that SlabCheck() doesn't free the freechunks it
> > allocates.
>
> > It's on its own obviously trivial to fix.
>
> It seems like having a context check function do new allocations
> is something to be avoided in the first place.

Yea, that's why I was wondering about doing the allocation during
context creation, for the largest size necessary of any context:

    /* bitmap of free chunks on a block */
    freechunks = palloc(slab->chunksPerBlock * sizeof(bool));

or at the very least using malloc(), rather than another context.


> It's basically assuming that the memory management mechanism is sane,
> which makes the whole thing fundamentally circular, even if it's
> relying on some other context to be sane.  Is there a way to do the
> checking without extra allocations?

Probably not easily.

Was wondering if the bitmap could be made more dense, and allocated on
the stack. It could actually using one bit for each tracked chunk,
instead of one byte. Would have to put in a clear lower limit of the
allowed chunk size, in relation to the block size, however, to stay in a
reasonable range.

Greetings,

Andres Freund



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

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: relcache sometimes initially ignores has_generated_stored
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SlabCheck leaks memory into TopMemoryContext