Page MenuHomeFreeBSD

Implement the Free Memory Fragmentation Index (FMFI) metric
Needs ReviewPublic

Authored by bnovkov on Jun 16 2023, 7:35 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Dec 1, 8:40 PM
Unknown Object (File)
Sat, Nov 23, 8:17 PM
Unknown Object (File)
Sat, Nov 23, 11:38 AM
Unknown Object (File)
Mon, Nov 18, 6:29 PM
Unknown Object (File)
Mon, Nov 18, 6:29 PM
Unknown Object (File)
Mon, Nov 18, 6:29 PM
Unknown Object (File)
Mon, Nov 18, 6:09 PM
Unknown Object (File)
Sun, Nov 17, 6:12 AM

Details

Reviewers
markj
Summary

This patch adds the Free Memory Fragmentation Index (FMFI) metric to the vm_phys subsystem.

The FMFI metric measures the degree of physical memory fragmentation for a given order by using metadata from the buddy allocator freelists.
Its value ranges from arbitrary negative values up to 1. A negative value implies that there is ample memory to serve an allocation request of the given order.
A value between 0 (no fragmentation) and 1 (highly fragmented) indicates the degree of physical memory fragmentation.

This work was sponsored by the Google Summer of Code program.

Test Plan

This metric is regularly used in academic papers regarding superpage management and is also used in the Linux kernel's memory compaction subsystem.
More information on this metric is available at the following link.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

Handle possible divide-by-zero exception when info.free_blocks is 0.

The summary tells the value ranges from 0 to 1. The reality is that it ranges from INT_MIN to 1000.

sys/vm/vm_phys.c
332

Wouldn't it make more sense to return 1000 here?

One could argue if no free memory means no fragmentation or too fragmented, but in the end no memory means an allocation can not be satisfied at all, which is similar to the highest fragmentation possible than no fragmentation at all.

sys/vm/vm_phys.c
332

Hm, I think it is important to treat this as a separate case since the returned value will be used to determine whether compaction should run or not.
For values close to 1000 it makes sense to run compaction, whereas in this out-of-memory case running compaction would just burn CPU cycles with no effect.

sys/vm/vm_phys.c
332

I suggest to add this info as a comment there.