Re: SlabCheck leaks memory into TopMemoryContext

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tv(at)fuzzy(dot)cz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SlabCheck leaks memory into TopMemoryContext
Date: 2020-01-17 14:40:04
Message-ID: 20200117144004.k3rjrypctn55mqnh@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Jan 16, 2020 at 01:41:39PM -0500, Tom Lane wrote:
>Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2020-01-16 18:01:53 +0100, Tomas Vondra wrote:
>>> and it's only really used in debug builds anyway. So I'm not all that
>>> woried about this wasting a couple extra kB of memory.
>> IDK, making memory usage look different makes optimizing it harder. Not
>> a hard rule, obviously, but ...
>Well, if you're that excited about it, make a patch so we can see
>how ugly it ends up being.

I think the question is how much memory would using globals actually
save, compared to including the bitmap in SlabContext.

The bitmap size depends on block/chunk size - I don't know what
parameters Andres uses for the additional contexts, but for the two
places already using Slab we have 8kB blocks with 80B and 240B chunks,
so ~102 and ~34 chunks in a block. So it's not a huge amount, and we
could easily reduce this to 1/8 by switching to a proper bitmap.


Tomas Vondra
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2020-01-17 15:48:53 Re: Expose lock group leader pid in pg_stat_activity
Previous Message Stephen Frost 2020-01-17 14:37:17 Re: Complete data erasure