Re: PATCH: two slab-like memory allocators - Mailing list pgsql-hackers

Hi Tomas,

On 02/08/16 17:44, Tomas Vondra wrote:
> 
> This patch actually includes two new memory allocators (not one). Very
> brief summary (for more detailed explanation of the ideas, see comments
> at the beginning of slab.c and genslab.c):
> 
> Slab
> ----
> * suitable for fixed-length allocations (other pallocs fail)
> * much simpler than AllocSet (no global freelist management etc.)
> * free space is tracked per block (using a simple bitmap)
> * which allows freeing the block once all chunks are freed (AllocSet
> will hold the memory forever, in the hope of reusing it)
> 
> GenSlab
> -------
> * suitable for non-fixed-length allocations, but with chunks of mostly
> the same size (initially unknown, the context will tune itself)
> * a combination AllocSet and Slab (or a sequence of Slab allocators)
> * the goal is to do most allocations in Slab context
> * there's always a single 'current' Slab context, and every now and and
> then it's replaced with a new generation (with the chunk size computed
> from recent requests)
> * the AllocSet context is used for chunks too large for current Slab
> 

So it's just wrapper around the other two allocators to make this
usecase easier to handle. Do you expect there will be use for the
GenSlab eventually outside of the reoderbuffer?

> So none of this is meant as a universal replacement of AllocSet, but in
> the suitable cases the results seem really promising. For example for
> the simple test query in [1], the performance improvement is this:
> 
>         N |   master |  patched
>    -----------------------------
>     10000 |    100ms |    100ms
>     50000 |  15000ms |    350ms
>    100000 | 146000ms |    700ms
>    200000 |        ? |   1400ms
> 
> That's a fairly significant improvement, and the submitted version of
> the patches should perform even better (~2x, IIRC).
> 

I agree that it improves performance quite nicely and that reoderbuffer
could use this.

About the code. I am not quite sure that this needs to be split into two
patches especially if 1/3 of the second patch is the removal of the code
added by the first one and otherwise it's quite small and
straightforward. That is unless you expect the GenSlab to not go in.

Slab:
In general it seems understandable, the initial description helps to
understand what's happening well enough.

One thing I don't understand however is why the freelist is both array
and doubly linked list and why there is new implementation of said
doubly linked list given that we have dlist.

> +/*
> + * SlabContext is our standard implementation of MemoryContext.
> + *

Really?

> +/*
> + * SlabChunk
> + *        The prefix of each piece of memory in an SlabBlock
> + *
> + * NB: this MUST match StandardChunkHeader as defined by utils/memutils.h.
> + */

Is this true? Why? And if it is then why doesn't the SlabChunk actually
match the StandardChunkHeader?

> +#define SlabPointerIsValid(pointer) PointerIsValid(pointer)

What's the point of this given that it's defined in the .c file?


> +static void *
> +SlabAlloc(MemoryContext context, Size size)
> +{
> +    Slab    set = (Slab) context;
> +    SlabBlock    block;
> +    SlabChunk    chunk;
> +    int            idx;
> +
> +    AssertArg(SlabIsValid(set));
> +
> +    Assert(size == set->chunkSize);

I wonder if there should be stronger protection (ie, elog) for the size
matching.


> +static void *
> +SlabRealloc(MemoryContext context, void *pointer, Size size)
> +{
> +    Slab    set = (Slab)context;
> +
> +    /* can't do actual realloc with slab, but let's try to be gentle */
> +    if (size == set->chunkSize)
> +        return pointer;
> +
> +    /* we can't really do repalloc with this allocator */
> +    Assert(false);

This IMHO should definitely be elog.


> +static void
> +SlabCheck(MemoryContext context)
> +{
> +    /* FIXME */
> +}

Do you plan to implement this interface?

> +#define SLAB_DEFAULT_BLOCK_SIZE        8192
> +#define SLAB_LARGE_BLOCK_SIZE        (8 * 1024 * 1024)

I am guessing this is based on max_cached_tuplebufs? Maybe these could
be written with same style?

GenSlab:

Since this is relatively simple wrapper it looks mostly ok to me. The
only issue I have here is that I am not quite sure about those FIXME
functions (Free, Realloc, GetChunkSpace). It's slightly weird to call to
mcxt but I guess the alternative there is to error out so this is
probably preferable. Would want to hear other opinions here.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services