Resources | Resources |



Tuning split heap configuration

The tuning process for the split heap usually needs to be repeated to determine the best values for split heap parameter. The best parameter set is usually tied to the use cases being tested.


    In a typical system, the majority of the heap allocations are small in size (less than 1K). Many of these allocations are from the system, or part of the process of creating objects. Because of the number and the great variety of owners for these small heap nodes, it is very difficult to predict the life cycle of these nodes. Because nodes with a long life cycle are typically the cause of memory fragmentation, it is also difficult to case-by-case reduce fragmentation. The goal of split heap is to isolate these small heap nodes in the small heap, and reduce their impact on allocation of large heap nodes.

    The recommended value for CS_KHEAP_SMALL_THRESHOLD is 4K to 8K. There is a tradeoff in selecting this value. A smaller threshold will cause the small heap to be less fragmented (no fragmentation block can be bigger than the threshold in small heap) but will push more heap allocations into the large heap, which causes a greater chance of fragmentation in the large heap. The other factor to consider is that some applications and modules use a sub-allocator with an allocation size in the 4 to 8K range. If these blocks can have a long life cycle, it is better to keep them in the small heap to avoid fragmentation in the large heap.

    The Heap Analyzer can be used to help determine a good threshold value. This tool shows all currently allocated nodes and their sizes. You can determine how many nodes are smaller than the threshold to be used. You can also take multiple heap snapshots to find the heap nodes with a long life cycle and determine whether you can increase the threshold to put them into the small heap.


    Turning on this flag allows a small heap allocation to be allocated from the large heap when the small heap runs out of space. With this flag on, it is easier to select the small heap and big heap sizes (see below). You can be conservative in selecting the small heap size since the allocation will still succeed when it runs out space. The trade-off is that when the small heap nodes spill over into the large heap, the large heap is more likely to fragment. The recommendation is to do your best in selecting the small heap size first, and then turn on spillover to allow the device to survive longer if unpredicted use cases or memory leaks from small nodes occur.


    After the small heap threshold is selected, you can determine the sizes for small and large heap. The goal is for both small and large heap to have successful allocations for as long as possible. Optimizing these sizes involves a large amount of testing with good coverage of use cases. It is typically inevitable to have memory leaks (especially in the small heap), and the testing needs to be repeated over a long period of time.

    The test process is as follows:

    1. Define a set of use cases that can be automated, then repeated randomly.
    2. Select a small heap threshold aggressively towards one side.
    3. Run the test until one of the either heap fails to allocate the requested memory.
    4. Make adjustments to the small heap size.
    5. Repeat the tests until both small and large heap survive for the longest possible time.

    You can also turn on spillover and run the device until it crashes, then adjust the CS_HEAP_SMALL_SIZE value based on fragmentation/heap node analysis for the small and large heap.

    Note: During the testing process, the long lived heap nodes need to be identified and eliminated whenever possible.