Open keszybz opened 1 year ago
nabijaczleweli
commented
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?
keszybz
commented
1 year ago 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…)
FallingSnow
commented
1 year ago 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.
FallingSnow
commented
1 year ago 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.
Atrate
commented
1 day ago Related to #197. Actually, this issue is exactly what I was experiencing, though under Xen and not QEMU/KVM.
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.serviceis 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_balloonstate from within the machine.