View Issue Details

IDProjectCategoryView StatusLast Update
0000777LDMud 3.6Generalpublic2022-10-06 18:40
Reporterzesstra Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status newResolutionopen 
Target Version3.6.0 
Summary0000777: Remove memory fragmentation related configuration switches
DescriptionIt would be nice to remove the following switches (so remove their behaviour OR remove the conditional use): USE_AVL_FREELIST, MALLOC_ORDER_LARGE_FREELISTS and MALLOC_ORDER_SLAB_FREELISTS.

As Gnomi mentioned in 0000663:0001229 we should try to measure their impact on fragmentation.
A possibility for this might be the idea sketched in 0000663:0001232.
Additional Informationhttp://blog.pavlov.net/2007/11/10/memory-fragmentation/
TagsNo tags attached.

Relationships

related to 0000783 assignedzesstra Change documentation to explain small_min_malloc and that it is only used in smalloc 

Activities

Coogan

2011-02-24 00:27

reporter   ~0002033

In Tubmud, I did not use any of them. Which muds do use them?

zesstra

2011-02-24 09:12

administrator   ~0002038

Actually, they are defined by default (on 3.3.x) and not configurable by configure. ;-) (Along with SLABALLOC_DYNAMIC_SLABS, MALLOC_EXT_STATISTICS, EXT_STRING_STATS.)

zesstra

2011-05-26 20:21

administrator   ~0002051

Last edited: 2022-10-06 18:40

I created some experimental patches to create images of the usage state of the memory after garbage collections. I hope, they will give us a hint about memory fragmentation...
The code is in the branch mem_image at https://github.com/zesstra/ldmud/commits/mem_image.
To use the stuff (warning: I don' recommend it for live muds), just apply the patches in that branch / switch to the branch and run the garbage collector. The driver will then create ppm images - they are huge (3/4 or 5/8 of the allocated memory) and should be compressed ASAP (PNG are fine). Supply enough disk space! ;-)
Colour legend: free large blocks: black, allocated large blocks: red, free small blocks: lightgray, allocated small blocks: blue.

zesstra

2011-05-27 08:18

administrator   ~0002054

I noticed with slaballoc a rather intimate mixture of small and large block areas (e.g. isolated large blocks in the midst of small blocks), which seems to be disadvantageous, because these large blocks will probably never be joined with other large blocks when freed. Also the OS may be less effective in finding rarely used pages for swapping.
Some spontaneous ideas:
1) increase the desired slab size / small chunk size. This is for slaballoc 4KB and seems rather on the small side considering modern amounts of memory. (BTW: Should be probably a multiple of pagesize?)
2) increase the retention time for free slabs from 60s to something significantly more (they will be always free'd in during GC)
3) introduce some MB of pre-allocated small block space by default? For smalloc this is currently 3 times the small chunk size which is not much.

Gnomi

2021-04-16 18:43

manager   ~0002593

We should also measure, which of both allocators (smalloc, slaballoc) performs better and then get rid of the other one.

Issue History

Date Modified Username Field Change
2011-02-14 14:14 zesstra New Issue
2011-02-14 14:15 zesstra Relationship added child of 0000663
2011-02-14 14:15 zesstra Assigned To => zesstra
2011-02-14 14:15 zesstra Status new => feedback
2011-02-14 14:24 zesstra Assigned To zesstra =>
2011-02-24 00:27 Coogan Note Added: 0002033
2011-02-24 09:12 zesstra Note Added: 0002038
2011-02-24 09:12 zesstra Status feedback => new
2011-05-26 20:21 zesstra Note Added: 0002051
2011-05-27 07:41 zesstra Relationship added related to 0000783
2011-05-27 08:18 zesstra Note Added: 0002054
2015-04-29 19:00 zesstra Project LDMud 3.5 => LDMud 3.6
2015-04-29 19:00 zesstra Category Implementation => General
2015-04-29 19:03 zesstra Target Version 3.5.0 => 3.6.0
2015-05-06 18:22 zesstra Relationship deleted child of 0000663
2021-04-16 18:43 Gnomi Note Added: 0002593
2022-10-06 18:40 zesstra Note Edited: 0002051