It doesn't really make sense to ask "how much memory is this process using?" Instead, you want to ask questions like "how much memory are all of these processes using?" or "how much memory would be freed if I terminate these processes?" or "how much extra memory will be used if I start another process?"
What's hard is understanding which question you want to ask in any given situation.
There's no right way to do it.
What's hard is understanding which question you want to
ask in any given situation.
I don't see the issue. You admit that answering all of these questions is easy. The hard part is lawyering which question to ask.This is not a data reporting problem.
This is a data interpretation problem.
A good reporting tool should not be interpreting (or forcing an opinion) on the end user.
You believe this problem is hard because you are forcing an interpretation to exist before you take a measurement. When you should not be interpreting until after measurement. Injecting an interpretation into a measurement process fundamentally changes that measurement.
Measurements inform your interpretation. Not the opposite.
TL;DR You put the cart in front of the horse.
That's what I said. "Defining it is what's hard."
You seem to understand what I'm saying, and agree with me, but insist on arguing for some reason I cannot comprehend.
You seem to understand what I'm saying
and agree with me
Literally the opposite. Your initial statement was Measuring memory usage is hard on a modern OS.
Which you've agreed was false as /proc/$PID/maps is easy to read. Then said: Defining it is what's hard
But these statements are not mutually inclusive nor does the later imply the former.I stated measuring is literally the simplest thing. You said ah but what you measuring. That isn't dependent on the tools, or OS. So why did you state it was?
Are you just arguing with me because you didn't realize I was somebody else?
The semantics that each process is sharing 5 HUGEPAGES of heap isn't really important as even if 1 was running alone it uses that much memory.
If you are sharing that much data with executables that you have this problem there is some low hanging fruit for memory optimizations you can do.
Indeed. And in cases where these 3 children have the same parent you look at the ParentMem + 40MB (child binary+individual heaps) to report a better picture.Shared/unshared semantics are not hard. Have you ever read /proc/$PID/maps ? Because it clearly labels what is/isn't shared physically. When you are optimizing for memory usage you rarely look at shared readonly pages as the kernel put them there for you.
Injecting an interpretation before taking a measurement is not sound science or engineering.Measurements inform Interpretation. Not vice versa.