3 ms·
Defining it is what's hard. how much memory is each process using? 20MB. Oh but they are sharing the pages the executable is mapped into. So how c
by valarauca1 10y ago
Defining it is what's hard.
how much memory is each process using?
20MB.
Oh but they are sharing the pages the executable is mapped into.
So how can you can you say they are each using that much RAM?
Because that 10MB of RAM won't be freed until the last process exits. Each process is using 20MB of physical pages. If only 1 was running it would use 20MB.
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.
Oh but you aren't *actually* using 60MB of Heap, only 40MB
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.
Defining it is what's hard.
Injecting an interpretation before taking a measurement is not sound science or engineering.
Measurements inform Interpretation. Not vice versa.
- mikeash 10y agoSure, shared/unshared semantics are not hard. How do you map that to a generic concept of "usage"? There's no right way to do it. 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.
- valarauca1 10y agoThere'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.
- mikeash 10y ago"This is a data interpretation problem." 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.
- valarauca1 10y agoYou 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?
- mikeash 10y agoNooooo... somebody else made that initial statement. My initial statement was "Measuring it is easy. Defining it is what's hard." Are you just arguing with me because you didn't realize I was somebody else?