SUMMARY Please add the actual allocated memory of a process as a potential choice of a column for the process monitor, specifically I mean the portion of memory that the process is using out of /proc/meminfo's total Committed_AS. This column is relevant in case of 1. using a system with overcommitting disabled, which is a useful mode to run in for various reasons like for example to test in an environment more similar to MS Windows which act the same, and 2. could also be useful for tracking down programs that excessively use fork() in situations where they should probably be using vfork() instead. STEPS TO REPRODUCE 1. Open up KDE plasma system monitor 2. Open the "Processes" page 3. Click "Configure Columns" button which should be somewhere in the top-right 4. Search through the column list to find actual allocation size of process. There's "Shared Memory Usage" and others, but no allocation size. OBSERVED RESULT There apparently isn't a suitable column that allows checking what proportion of /proc/meminfo's Committed_AS measure an individual process is respectively using up. EXPECTED RESULT There should be a suitable column that allows checking what proportion of /proc/meminfo's Committed_AS measure an individual process is respectively using up. SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: postmarketOS Edge KDE Plasma Version: 6.4.2 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 ADDITIONAL INFORMATION
The problem is that I don't think there is a per-process equivalent to `Committed_AS`. Per-process stats are read from files in `/proc/$PID` which do not have the same format as `/proc/meminfo`. For memory specifically, we combine data from `/proc/$PID/stat`, `/proc/$PID/statm` and `/proc/$PID/smaps_rollup`. Neither of those files has anything relating to "committed". Without a per-process value provided by the kernel we can't really do a lot.
Closing as per #1
I was once suggested /proc/$PID/smaps might something useful here, but I have to admit I'm not an expert. Apparently this is what the common smem tool uses. It seems to list mappings which perhaps could correspond to committed memory ranges? Not that I would know how exactly this works.
Here is some more information: https://unix.stackexchange.com/questions/797974/how-to-find-out-a-processs-proportional-use-of-system-wide-committed-as-memory An approximate value that doesn't take sharing into account seems to be VmSize, and a proportional one seems to be to go through /proc/*/smem and add up all the ranges for a single process, but then for the shared mapping, divide them by the number of other processes also using them.
Nevermind, I just found VmSize is probably a way too high number and not the correct one. My apologies for the noise. Will update with another comment once I found out what the correct data source is.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.