Open keszybz opened 1 year ago
Tempted to say "works as expected", right? When the system has 2G of MemTotal attached ram
is 2G in zram-size, and with 8G – 8G. Way I see it, balloon is just memory hot-plug?
I don't think it can be considered to "work". First of all, the size is subject to a race condition on every boot. Second, I don't think it's useful to scale to Maximum, because for most VMs that is not relevant, and could possibly be many times higher than Current. You end up with a swap device that is too large for the amount of available RAM; there is no way that 8GB zram device can be filled with 2GB RAM available. (E.g. I can imagine a VM host with 256GB of RAM that is used for a hundred VMs, each configured by default with Current/Maximum of 2/32, just in case a VM needs to be dynamically scaled at some later point…)
My situation is somewhat similar. I'm using virtio-mem. The system boots with 1G of ram and once the virtio-mem
kernel module loads the system has access to an additional 15GB of ram. However the system's zram is set to 1G since that was the size of ram at boot.
I suppose this is works as intended but it would be nice-to-have if zram-generator detects memory hot-plugging automatically. Since this changes current behavior maybe it could be hidden behind a config option.
I've come up with two possible solutions.
After=systemd-modules-load.service
to the zram systemd file. This is not dynamic and only solves the low zram size at boot.virtio-mem
module: https://github.com/torvalds/linux/blob/533925cb760431cb496a8c965cfd765a1a21d37e/drivers/virtio/virtio_mem.c#L2558-L2559. We could generate bindings for linux/memory.h
and linux/notifier.h
to use this system.
I have a VM with a large Maximum allocation of 8 GB and Current allocation of 2 GB. It seems that during boot, the ballooning process is so slow, that
systemd-zram-setup@zram0.service
is executed early enough to see the "wrong" size. If I restart the unit later on, zram0 is recreated with the expected size (==RAM).I can't find a reference, but I'm pretty sure we had an issue about this previously when the zram0 device was created directly in the generator. Later on, when we switched to creating of the zram0 device in the unit, this problem "went away", because this step happens a bit later. But it seems that something changed, and the service now runs earlier.
This is ugly… I don't see any source of information about
virtio_balloon
state from within the machine.