On Tue, 16 Apr 2024 at 17:13, Amul Sul <sula...@gmail.com> wrote: > Attached is a small patch adding the missing BumpContext description to the > README.
Thanks for noticing and working on the patch. There were a few things that were not quite accurate or are misleading: 1. > +These three memory contexts aim to free memory back to the operating system That's not true for bump. It's the worst of the 4. Worse than aset. It only returns memory when the context is reset/deleted. 2. "These memory contexts were initially developed for ReorderBuffer, but may be useful elsewhere as long as the allocation patterns match." The above isn't true for bump. It was written for tuplesort. I think we can just remove that part now. Slab and generation are both old enough not to care why they were conceived. Also since adding bump, I think the choice of which memory context to use is about 33% harder than it used to be when there were only 3 context types. I think this warrants giving more detail on what these 3 special-purpose memory allocators are good for. I've added more details in the attached patch. This includes more details about freeing malloc'd blocks I've tried to detail out enough of the specialities of the context type without going into extensive detail. My hope is that there will be enough detail for someone to choose the most suitable looking one and head over to the corresponding .c file to find out more. Is that about the right level of detail? David
diff --git a/src/backend/utils/mmgr/README b/src/backend/utils/mmgr/README index f484f7d6f5..695088bb66 100644 --- a/src/backend/utils/mmgr/README +++ b/src/backend/utils/mmgr/README @@ -471,25 +471,32 @@ thrashing. Alternative Memory Context Implementations ------------------------------------------ -aset.c is our default general-purpose implementation, working fine -in most situations. We also have two implementations optimized for -special use cases, providing either better performance or lower memory -usage compared to aset.c (or both). - -* slab.c (SlabContext) is designed for allocations of fixed-length - chunks, and does not allow allocations of chunks with different size. - -* generation.c (GenerationContext) is designed for cases when chunks - are allocated in groups with similar lifespan (generations), or - roughly in FIFO order. - -Both memory contexts aim to free memory back to the operating system -(unlike aset.c, which keeps the freed chunks in a freelist, and only -returns the memory when reset/deleted). - -These memory contexts were initially developed for ReorderBuffer, but -may be useful elsewhere as long as the allocation patterns match. - +aset.c (AllocSetContext) is our default general-purpose allocator. Three other +allocator types also exist which are special-purpose: + +* slab.c (SlabContext) is designed for allocations of fixed-sized + chunks. The fixed chunk size must be specified when creating the context. + New chunks are allocated to the fullest block, keeping used chunks densely + packed together to avoid memory fragmentation. This also increases the + chances that pfree'ing a chunk will result in a block becoming empty of all + chunks and allow it to be free'd back to the operating system. + +* generation.c (GenerationContext) is best suited for cases when chunks are + allocated in groups with similar lifespan (generations), or roughly in FIFO + order. No attempt is made to reuse space left by pfree'd chunks. Blocks + are returned to the operating system when all chunks on them have been + pfree'd. + +* bump.c (BumpContext) is best suited for use cases that require densely + allocated chunks of memory that never need to be individually pfree'd or + repalloc'd. These operations are unsupported due to BumpContext chunks + having no chunk header. No chunk header means more densely packed chunks, + which is especially useful for workloads that perform lots of small + allocations. Blocks are only free'd back to the operating system when the + context is reset or deleted. + +For further details, please read the header comment in the corresponding .c +file. Memory Accounting -----------------
