You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rework VMM reservoir sizing to scale better with memory configurations (#7837)
The core observation of this change is that some uses of memory are relatively fixed regardless of a sled's hardware configuration. By subtracting these more constrained uses of memory before calculating a VMM reservoir size, the remaining memory will be used mostly for services that scale either with the amount of physical memory or the amount of storage installed.
The new `control_plane_memory_earmark_mb` setting for sled-agent describes the sum of this fixed allocation, and existing sled-agent config.toml files are updated so that actual VMM reservoir sizes for Gimlets with 1TB of installed memory are about the same:
Before: `1012 * 0.8 => 809.6 GiB` of VMM reservoir
After: (1012 - (30.0 / 1024 * 1012) - 44) * 0.863 => 809.797 GiB` of VMM reservoir
A Gimlet with 2 TiB of DRAM sees a larger VMM reservoir:
Before: `2036 * 0.8 => 1628.8 GiB` of VMM reservoir
After: `(2036 - (60.0 / 2048 * 2036) - 44) * 0.863 => 1667.62 GiB` of VMM reservoir
These actual observed figures are close-but-not-exact because the amount of physical memory illumos reports looks to be about 25 MiB less.
A Gimlet with less than 1 TiB of DRAM would see a smaller VMM reservoir, but this is in some sense correct: we would otherwise "overprovision" the VMM reservoir and eat into what is currently effectively a slush fund of memory for Oxide services supporting the rack's operation, risking overall system stability if inferring from observation and testing on systems with 1 TiB gimlets.
A useful additional step in the direction of "config that is workable across SKUs" would be to measure Crucible overhead in the context of number of disks or total installed storage. Then we could calculate the VMM reservoir after subtracting the maximum memory expected to be used by Crucible if all storage was allocated, and have a presumably-higher VMM reservoir percentage for the yet-smaller slice of system memory that is not otherwise accounted.
Fixes#7448.
0 commit comments