forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commitd21ded7
committed
Improve the performance of the slab memory allocator
Slab has traditionally been fairly slow when compared with the AllocSet orGeneration memory allocators. Part of this slowness came from having towrite out an entire block when we allocate a new block in order topopulate the free list indexes within the block's memory. Additionalslowness came from having to move a block onto another dlist each time wepalloc or pfree a chunk from it.Here we optimize both of those cases and do a little bit extra to improvethe performance of the slab allocator.Here, instead of writing out the free list indexes when allocating a newblock, we introduce the concept of "unused" chunks. When a block is firstallocated all chunks are unused. These chunks only make it onto thefree list when they are pfree'd. When allocating new chunks on anexisting block, we have the choice of consuming a chunk from the free listor an unused chunk. When both exist, we opt to use one from the freelist, as these have been used already and the memory of them is morelikely to be cached by the CPU.Here we also reduce the number of block lists from there being one forevery possible value of free chunks on a block to just having a smallfixed number of block lists. We keep the 0th block list for completelyfull blocks and anything else stores blocks for some range of free chunkswith fuller blocks appearing on lower block list array elements. Thisreduces how often we must move a block to another list when we allocate orfree chunks, but still allows us to prefer to put new chunks on fullerblocks and perhaps allow blocks with fewer chunks to be free'd lateronce all their remaining chunks have been pfree'd.Additionally, we now store a list of "emptyblocks", which are blocks thatno longer contain any allocated chunks. We now keep up to 10 of thesearound to avoid having to thrash malloc/free when allocation patternscontinually cause blocks to become free of any allocated chunks only toallocate more chunks again. Now only once we have 10 of these, we freethe block. This does raise the high water mark for the total memory thata slab context can consume. It does not seem entirely unreasonable thatwe might one day want to make this a property of SlabContext rather than acompile-time constant. Let's wait and see if there is any evidence tosupport that this is required before doing it.Author: Andres Freund, David RowleyTested-by: Tomas Vondra, John NaylorDiscussion:https://postgr.es/m/20210717194333.mr5io3zup3kxahfm@alap3.anarazel.de1 parent995a9fb commitd21ded7
1 file changed
+524
-276
lines changed0 commit comments
Comments
(0)