Short summary about what that file contains and why it can be useful (for us)
would be great to have as context here.
Am 23.05.25 um 18:37 schrieb Aaron Lauterer:
> Signed-off-by: Aaron Lauterer <a.laute...@proxmox.com>
> ---
> src/PVE/ProcFSTools.pm | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/src/PVE/ProcFSTools.pm b/src/PVE/ProcFSTools.pm
> index 382e6c5..185b2b3 100644
> --- a/src/PVE/ProcFSTools.pm
> +++ b/src/PVE/ProcFSTools.pm
> @@ -344,6 +344,20 @@ sub read_meminfo {
> return $res;
> }
>
> +# extract memory data from /proc/$pid/smaps_rollup for PID. $value is e.g.
> "Pss".
> +sub read_smaps_rollup {
> + my ($pid, $value) = @_;
> +
> + my $res = 0;
> + return $res if !$pid || !$value;
> +
> + my $mem_stats = eval {
> PVE::Tools::file_get_contents("/proc/${pid}/smaps_rollup") };
> + if ($mem_stats && $mem_stats =~ m/^${value}:\s+(\d+)\s*kB$/m) {
is this an efficient interface? A caller needing more than one handful will
cause a full read of the file and regex match applied to that, granted, it's
not huge, but that's still not really a good excuse...
As of now this is really not better than just doing the same on a call site
directly. A method in such a generic interface should do better and return
a parsed list of values as hash.
> + $res = $1 * 1024;
> + }
> + return $res;
> +}
> +
> # memory usage of current process
> sub read_memory_usage {
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
