On 2025-11-25 16:20, Thomas Lamprecht wrote:
Am 25.11.25 um 15:20 schrieb Fabian Grünbichler:
On November 25, 2025 3:08 pm, Thomas Lamprecht wrote:
Just to be sure: The stats from memory.current or memory.stat inside the
/sys/fs/cgroup/qemu.slice/${vmid}.scope/ directory is definitively not
enough for our usecases?
well, if we go for RSS they might be, for PSS they are not, since that
doesn't exist there?
Would need to take a closer look to tell for sure, but from a quick check
it indeed seems to not be there.
having the live view and the metrics use different semantics seems kinda
confusing tbh..
more than jumping between metrics over time silently? ;-) The live view can
be easily annotated with a different label or the like if the source is
another, not so easy for metrics.
The more I think about this the more I'm in favor of just deprecating this
again completely, this page table walking can even cause some latency spikes
in the target process, IMO just not worth it. If the kernel can give us this
free, or at least much cheaper, in the future, then great, but until then it's
not really an option. If, we can make this opt-in. The best granularity here
probably would be through guest config, but for starters a cluster-wide
datacenter option could be already enough for the setups that are fine with
this performance trade-off in general.
If I may add my 2 cents here. How much do we lose by switching
completely to fetching RSS (or the cgroupv2 equivalent)? For the metrics
and live view.
AFAIU the resulting memory accounting will be a bit higher, as shared
libraries will be fully accounted for for each cgroup and not
proportionally as with PSS.
I am not sure if we want to introduce additional config options (global
per DC, or per guest) to change the behavior. As that is probably even
more confusing for not that much gain.
And its not like PSS doesn't come with its own set of weirdness. E.g.,
if we run 10 VMs, and stop all but one, the last will see an increase in
memory consumption as it is the sole user of shared libraries.
_______________________________________________
pve-devel mailing list
[email protected]
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
_______________________________________________
pve-devel mailing list
[email protected]
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
