Memory Management Goop in Windows and Linux
Get some insight on the different ways Windows and Linux manage memory.
Join the DZone community and get the full member experience.
Join For FreeRegardless of the operating system you use, you are going to get roughly the same services from each of them. In particular, process and memory isolation, managing the hardware, etc. It can sometimes be really interesting to see the difference between the operating systems approach to solving the same problem. Case in point, how both Windows and Linux manage memory. Both of them run on the same hardware and do roughly the same thing. But they have very different styles, this ends up having profound implications on the application using them.
Consider what appears to be a very simple question, what stuff do I have in my RAM? Linux keeps track of Resident Set Size on a per-mapping basis, which means that we are able to figure out how much of a mmap file is actually in memory. Furthermore, we can figure out how much of the mmap data is clean, which means that it is easily discardable and how much is dirty and needs to be written to disk. Linux exposes this information via the /proc/[pid]/smaps.
On the other hand, Windows doesn’t seem to bother to do this tracking. You can get this information, but you need to ask it for each page individually. This means that it isn’t feasible to check what percentage of the system memory is clean (mmap pages that haven’t been modified and can be cheaply discarded). Windows expose this via the QueryWorkingSetEx method.
As a result, we have to be more conservative on Windows when the system reports high memory usage. We know that our usage pattern means a high amount of memory in use (coming from mmap clean pages) is fine. It is a small detail, but it has caused us to have to jump through several hurdles when we are running under load. I guess that Windows doesn’t need this information, so it isn’t exposed, while on Linux, it seems to be used by plenty of callers.
Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments