• MemoryFragmentationExperiments

Memory Fragmentation Experiments

Baseline measurements

Baseline measurements of free memory on the system

• Raw free - Total amount of memory (pre page allocator, primitive memory manager)
  • 425828352 bytes
• Machine booted
  • Statistical variation
    • 399835136, 399577088, 399634432, 400617472 (fresh reboots)
      • Seems to be a slight increase in the short time period after the system is read for login. Some processes finishing?
  • Idle (~0.5hr)
    • 401162240, 401166336, 401166336, 401166336
• Baseline user level (eg logged in)
  • 392515584

Controlled Experiments

Program which uses a known amount of memory (20%-80%)

• Measure amount of memory free and fragmentation before and after test has run

Notes:

• The test program is very simple - it does a printf, malloc, sleeps for a couple of seconds and then exits
• Experiments with 80% system memory allocation were done after rebooting the system
• There appears to be a small memory leak evertime the program is run. These numbers were generated with the PMLeafChunk class enabled and set to an allocation of 128k. However I reran the experiment (just with user and after 1000 runs) and verified there was a drop in free memory in the page allocator.

Free memory available after multiple runs of /home/regress/sysinit

• The page allocator has about 10Mb less memory free after each invocation of the regress
  • lost in the FCM's?
  Tried the following experiment starting with a freshly booted system

Benchmark that consumes a large percentage of system memory with a mix of long/short lived processes

SDET performance with difference chunk allocation sizes

Tests were run on k4. SDET numbers are average over single runSdet run(eg 24 runs)

Fragmentation after running K42 and linux regress tests

The following histogram displays the fragmentation of memory after running /home/regress/sysinit (eg k42 and linux regress tests without SDET). The 4k run was with the PMLeafChunk allocation disabled.

• I suspect something may be wrong with the implementation because I did not expect the fragmentation levels to begin increasing again after dropping initially (after 256kb chunk allocations).
• Significant fragmentation is occurring from other sources (eg file access)

Raw data is here: memory_frag_pmleafchunk_raw.txt

The table below displays the amount of memory free (table entry) which is available in contiguous size (row) versus the allocation size used by PMLeafChunk

Notes

• The 4k row shows how much memory is free (as seen by the PageAllocator). It is smaller with higher chunk allocation sizes because processes still running at the end of the test run are consuming more memory at higher allocation sizes.