Implement a policy for the balloon device so that it starts taking
memory away from the VM when the system is under low memory conditions.
There are a few pieces here:
* Change the madvise call in MemoryMapping::dont_need_range to use
MADV_REMOVE instead of MADV_DONTNEED. The latter does nothing when
the memory mapping is shared across multiple processes while the
former immediately gives the pages in the specified range back to the
kernel. Subsequent accesses to memory in that range returns zero
pages.
* Change the protocol between the balloon device process and the main
crosvm process. Previously, the device process expected the main
process to send it increments in the amount of memory consumed by the
balloon device. Now, it instead just expects the absolute value of
the memory that should be consumed. To properly implement the policy
the main process needs to keep track of the total memory consumed by
the balloon device so this makes it easier to handle all the policy in
one place.
* Add a policy for dealing with low memory situations. When the VM
starts up, we determine the maximum amount of memory that the balloon
device should consume:
* If the VM has more than 1.5GB of memory, the balloon device max is
the size of the VM memory minus 1GB.
* Otherwise, if the VM has at least 500MB, the balloon device max is
50% of the size of the VM memory.
* Otherwise, the max is 0.
The increment used to change the size of the balloon is defined as
1/16 of the max memory that the balloon device will consume. When the
crosvm main process detects that the system is low on memory, it
immediately increases the balloon size by the increment (unless it has
already reached the max). It then starts 2 timers: one to check for
low memory conditions again in 1 seconds (+ jitter) and another to
check if the system is no longer low on memory in 1 minute (+ jitter)
with a subsequent interval of 30 seconds (+ jitter).
Under persistent low memory conditions the balloon device will consume
the maximum memory after 16 seconds. Once there is enough available
memory the balloon size will shrink back down to 0 after at most 9
minutes.
BUG=chromium:866193
TEST=manual
Start 2 VMs and write out a large file (size > system RAM) in each.
Observe /sys/kernel/mm/chromeos-low_mem/available and see that the
available memory steadily decreases until it goes under the low memory
margin at which point the available memory bounces back up as crosvm
frees up pages.
CQ-DEPEND=CL:1152214
Change-Id: I2046729683aa081c9d7ed039d902ad11737c1d52
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1149155
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
The mmaps made through the sys_util API are usually for guest memory or
other large shared memory chunks that will pollute the file system with
huge dumps on crash. By using MADV_DONTDUMP, we save the file system
from storing these useless data segments when crosvm crashes.
TEST=./build_test
BUG=None
Change-Id: I2041523648cd7c150bbdbfceef589f42d3f9c2b9
Reviewed-on: https://chromium-review.googlesource.com/890279
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
This really should have been added along with the poll timeout support,
which changed the syscalls used in every jailed device.
TEST=run crosvm with sandboxing enabled
BUG=None
Change-Id: I6129fa589640bb2b85fb4274775192bdd49db672
Reviewed-on: https://chromium-review.googlesource.com/890379
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
The balloon device is used to take regions of unused memory from the
guest and allow other host processes to use that memory.
Change-Id: I06c821365a58672d605fc7555beaec599cae1b15
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/759306
Reviewed-by: Stephen Barber <smbarber@chromium.org>
