bhyve memory should exert memory pressure
When bhyve allocates memory for a guest (for the guest RAM, specifically) today, it does so in a
KM_NOSLEEP manner. This is to avoid the allocation entering an uninterruptable (by signals) sleep, but also results in the allocation bypassing logic which informs the rest of the system about the memory pressure exerted by the allocation. In order to make timely and reliable allocations, those page reservation mechanisms should be updated to allow requests which can apply that memory pressure (implying KM_SLEEP), but are also fallible and interruptable via signal, so that bhyve may be updated to use them.
Updated by Patrick Mooney 10 months ago
The canonical example for bhyve applying memory pressure is its ability to shrink the ARC. In order to test this, I booted up a machine with the proposed fix and then incurred disk activity (sequential data reads) until the ARC grew to an appreciable size (12GB out of the 64GB physmem). I then grew the size of the vmm memory reservoir (from #13833), observing it soaking up the remaining freemem on the system. Once freemem ran low, the dtrace probes I had attached to
arc_reap_cb began to fire, indicating that an arc reap (and subsequent shrink) was occurring. As I continued to grow the reservoir, making more memory available for bhyve's use, the ARC continued shrinking. This proceeded until the ARC was roughly 6GB in size, and it would not shrink any further. At that point, attempts to put more memory in the reservoir were unsuccessful and the system started to become unresponsive. The pending allocation was cancelled and the system was well again.
Updated by Electric Monk 10 months ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
commit b57f5d3e6a2df8d435e606797cf3934811848343 Author: Patrick Mooney <email@example.com> Date: 2021-07-27T19:26:22.000Z 13833 want bhyve memory reservoir 13822 bhyve memory should exert memory pressure 13834 want extensible page_resv 13821 vmmctl ioctls should have more structure Reviewed by: Andy Fiddaman <firstname.lastname@example.org> Reviewed by: Jason King <email@example.com> Reviewed by: Dan Cross <firstname.lastname@example.org> Reviewed by: Hans Rosenfeld <email@example.com> Reviewed by: Mike Zeller <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>