[pve-devel] [PATCH ksm-control-daemon] ksmtuned: fix large number processing

[Thomas Lamprecht]

Hi,

Am 28/02/2024 um 23:47 schrieb Roland:
> any reason why this did not get a response ?  (i do not see rejection of
> this  ,nor did it appear in
> https://git.proxmox.com/?p=ksm-control-daemon.git;a=summary )

No reason, but even if this looks pretty straight forward, positive
feedback would still help to speed this up – did you test this
successfully? Then I could apply it with a Tested-by: name <email>
trailer.

> 
> and, while we are at ksmtuned, i think it's is broken, especially when
> run on ZFS based installations, as it's totally mis-calculating ram
> ressources.
> 
> https://forum.proxmox.com/threads/ksm-is-needlessly-burning-cpu-because-of-using-vzs-and-ignoring-arcsize.142397/

Yeah KSM could definitively do with some more love, lets see if we can
allocate some dev time for this.

The RSS (which rsz is an alias for) vs. VSS (vsz aliased) looks
interesting, and VSS really seems to be the wrong thing to look at to me
(albeit without deeper inspection of the matter).

FWIW, depending on how the sum is used it might actually make even more
sense to use PSS, i.e., the proportional set size which better accounts
for shared memory by dividing that part between all its users, as if
e.g. 10 QEMU processes have 100 MB of shared code and what not in their
RSS, using RSS one would sum up 900 MB to much compared using PSS, but
what's the correct one here is then depending on how they result is
used.

@Stefan, as you checked this out, would you care checking out the VSS
vs. RSS vs. PSS matter too? I.e. checking what should make more sense to
use and actually testing that out in a somewhat defined workload.

The ZFS ARC thing is something else and might be a bit more complicated,
so I'd focus first one above at that seems to provide better
improvements for less work, or at least with less potential to build an
unstable control system.

thanks,
 Thomas