On Sun, Jan 10, 2021 at 09:34:49PM +0000, Anindya Mukherjee wrote:
> Hi, I'm trying to understand the various numbers reported for memory
> usage from top, vmstat, and systat. I'm running OpenBSD 6.8 on a Dell
> Optiplex 7040 with an i7 6700, 3.4 Ghz and 32 GB RAM. The GPU is an
> Intel HD Graphics 530, integrated. Everything is running smoothly. For
> my own edification, I have a few questions. I searched the mailing lists
> for similar questions in the past, and found some, but they did not
> fully satisfy my curiosity.
>
> dmesg reports:
> real mem = 34201006080 (32616MB)
> avail mem = 33149427712 (31613MB)
> I think the difference is due to the GPU reserving some memory.
That might be, I think it at least includes mem used by the kernel
for its code and static data.
> Q: Is there a way to view the total amount of video memory, the amount
> currently being used, and the GPU usage?
AFAIK not. Some bioses have settings for the video mem used (if you
have it shared with main mem).
>
> When I run top, it reports the following memory usage:
> Memory: Real: 1497M/4672M act/tot Free: 26G Cache: 2236M Swap: 0K/11G
> If I sum up the RES numbers for all the processes, it is close to the
> act number = 1497 M (this is mostly due to Firefox). I read that the
> cache number is included in tot, but even if I subtract cache and act
> from tot there is 939 MB left.
> Q: What is this 939 MB being used for, assuming the above makes sense?
inactive pages?
> Q: What is the cache number indicating exactly?
memoy used for file systemn caching.
>
> If I sum up tot + free * 1024 I get 31296 MB, which less than the 31613
> MB of available memory reported by dmesg. I initially assumed that the
> difference might be kernel wired memory. However the uvm view of systat
> shows 7514 wired pages = approx 30 MB which is very small.
> Q: What is the remaining memory being used for?
I think you are looking at dynamic allocations done by the kernel.
> Q: What is in kernel wired memory? In particular, is the file system
> cache in kernel wired memory or in the cache number?
Kernel wired means data pages allocated by the kernel that will not be
paged out. The file system mem will also not be paged out (when
evecting those they are discarded if not dirty or written to the file
if dirty) but the file system cache pages are not in the wired count.
> In the man page for systat(1) the active memory is described as being
> used by processes active in the last 20 seconds (recently), while the
> total is for all processes. These are the same two numbers as act and
> tot in top, and act = avm as reported by vmstat. This confused me
> because adding up the RES sizes of all the processes I get nowhere near
> to tot (even after subtracting cache).
Accounting of shared pages is hard and ambiguous. To illustrate: if
you switch on S in top, you'll see a bunch of kenel space processes al
at SIZE 0 and the same RES size. They do share the same (kernel)
memory.
>
> There is another thing that confused me in the top output. At first I
> assumed that SIZE is the total virtual memory size of the process
> (allocated), while RES is the resident size. For example, this is so on
> Linux and hence in that case by definition SIZE should always be greater
> than RES. However here in many cases SIZE < RES.
I am unsure how that is caused. It is possibly a shared pages thing.
>
> I read in the man page for top that SIZE is actually text + data + stack
> for the process. However this did not clear up my confusion or
> misunderstanding. Perhaps something to do with shared memory not being
> counted?
> Q: How can SIZE be less that RES? An example showing how this could
> happen would be really helpful.
I guess doing some experimenting and code analysis and share your findings.
>
> Q: Finally, where can I find documentation about the classification for
> memory pages (active, inactive, wired, etc.)? I suspect some digging
> around in the source in order, but could use some pointers.
The start would be man uvm_init. But the rest is code.
>
> I hope these make sense and are not too pedantic. Looking forward to
> comments from the experts, thanks!
>
> Anindya Mukherjee
>
-Otto
