View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000777 | LDMud 3.6 | General | public | 2011-02-14 14:14 | 2022-10-06 18:40 |
| Reporter | zesstra | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Target Version | 3.6.0 | ||||
| Summary | 0000777: Remove memory fragmentation related configuration switches | ||||
| Description | It 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 Information | http://blog.pavlov.net/2007/11/10/memory-fragmentation/ | ||||
| Tags | No tags attached. | ||||
|
|
In Tubmud, I did not use any of them. Which muds do use them? |
|
|
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.) |
|
|
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. |
|
|
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. |
|
|
We should also measure, which of both allocators (smalloc, slaballoc) performs better and then get rid of the other one. |
| 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 |
