The Memory Shell Game

re: The Memory Shell Game

Mel Calucin — Sun, 29 Mar 2009 22:41:41 GMT

Thanks for the great post.

If the Total Physical Memory is way more than the Peak Commit Charge, would there ever be the case where the memory manager will ever need to convert any of the standby page list to zero page list or free page list?

Also, is there a way to monitor the value of the standby page list without having to install Windows debugger?

Thanks.

[Yes. The Memory Manager many need to scavenge old pages from the standby list for a variety of reasons. Here are just two examples: 1) Processes starting and stopping - When a process starts, it will get pages from the zero, then the free page list. If there aren’t enough pages, the Memory Manager will pull pages off of the standby list. When a process terminates, its pages will be placed on the free page list. If there is more demand from staring processes than stopping ones, standby pages will be converted. 2) Memory demand from different processes. If some processes have a spike in memory consumption and that demand cannot be met from the free or zero page lists, then the Memory Manager will pull pages from the standby list. Some page churn can be expected as pages change ownership between processes and the system file cache. Typically you won’t notice this as the more used pages tend to remain in working sets or stay long enough on the standby page list to be soft faulted back in.]

re: The Memory Shell Game

Alex Zhdankin — Mon, 09 Jun 2008 12:15:27 GMT

Excellent article, thanks! So good, that I have some questions on it:

"If the process doesn't use the page for a very long time, or if the demand for the page is greater elsewhere, the page is moved off of the standby list."

1. What does that "very long time" actually mean: 10 seconds, 10 minutes, an hour or a week?

2. What is the reason to remove standby pages from RAM if there is no need in additional RAM?

Of course, there might be a demand for more available RAM for other processes in future, but likewise in future these standby pages might be required by the process they belong to.

[Here are the answers to your questions:

1. Good observation. The working set management algorithm is largely demand based. We try to balance current demand with possible future demand. If there aren't enough free or zeroed pages to meet the system's need, the working set manager will start trimming the least recently used pages. After the zeroed and free pages, we pull from the standby list. If there will never be any future demand, or there are always enough zeroed pages, then the standby list could remain as is. This scenario; however, will most likely never occur. There will always be demand for new pages. Dependent on your system's rate of demand for new pages, older pages on your standby list will be removed. There isn't a fixed time of when your standby page will be scrubbed and passed on, it is just tied system activities like file cache usage, process startup and end and current process memory usages. Given enough time and enough demand for new pages and if the process doesn't soft fault back in the standby page it will be recycled.

2. If there is no more demand for new pages then we don't remove pages from the standby list. This; however, usually is never the case. You system is almost always doing something with memory. Some processes are requesting new pages, others releasing some. Some processes may be working with cached I/O, other processes could be started or ending. There is always constant churn on the memory pages. Over time, typically you'll see older standby pages removed from the standby list and given to some thread that requested a new page. As long at this page continues to be used, it will remain active for the process. Eventually it may be freed or not used in a long time. If it sits long enough on the standby list, eventually it will most likely be recycled and given to someone else who needs it.]

re: The Memory Shell Game

David Solomon — Tue, 01 Jan 2008 21:29:55 GMT

Some errors in your definitions:

Committed Memory – "When an application touches a virtual memory page the page becomes a committed page. It is now backed by a physical memory page"

Not quite: a page becomes a "committed page" when an application commits virtual memory. At that time, the Memory Manager deducts from the system commit limit and charges it to the Commit Charge Total. If and when it is actually touched, then the memory manager backs it with a physical page (that part you had correctly).

Commit Limit - "If you had 50 applications fully allocate their 2 GB of virtual address space, you would need 100GB of commit limit (ignore kernel memory usage to keep the numbers simple)"

Not quite: if you had 50 applications fully allocate their 2GB with PRIVATE committed address space, then what you said is true - but if you had 50 apps with 2GB of committed READ ONLY memory (e.g. shared memory or memory mapped files), you would need little or no pagefile space (or RAM) to support this. Again, only private nonshareable process virtual memory counts against the commit limit (not shareable stuff like code in EXEs or DLLs).

Standby list: "It is still associated with the process, but not in its working set."

Not quite: it may not be associated with a process if all references to the file have been closed; however, it is still available to a future process that opens and references that cached file data.

PF Usage is wrong - it is (in Task Manager on XP) *identical* to Commit Charge Total. Your definition (# number of pages that have at one time been pulled out of a process' working set and committed to the page file) is completely off.

Also, my new instructor Alex Ionescu has a new tool (for Vista and Server 2008 - doesn't run on XP/2003) that shows a superset of system memory information than what the kernel debugger !meminfo shows - and unlike local kernel debugging on Vista which requires booting in Debugging Mode, this tool doesn't require that... see http://www.alex-ionescu.com/tools.zip (he will be posting a blog post on his site to explain these in the future).

David, Thanks for your feedback. Your clarifications are absolutely correct. The posting was written as a primer for memory manager concepts. It is hard to generalize this complex system. I had to keep the examples simple and brief to easily illustrate the basic concepts. Many things above have some purposefully omitted detail that can be explored further in your book (linked in the articled). Also, thanks for catching the PF Usage error. I’ve updated the definition above.

re: The Memory Shell Game

Sam Hobbs — Mon, 31 Dec 2007 23:50:26 GMT

This article truly is not clear about the relevance of the Commit Charge to performance. It is my understanding that for a specific combination of processes and such in a system, the Commit Charge will be the same regardlous of the amount of physical memory. Some people seem to think that the Commit Charge indicates whether pysical memory is adequate (or correspondingly inadequate) and if it does then I don't understand how Commit Charge is relevant.

re: The Memory Shell Game

Sam Hobbs — Mon, 31 Dec 2007 23:35:32 GMT

It is my understanding that executables (exe and dll files) are mapped into virtual storage but not all of them are always read into physical memory.

It is not clear to me whether the executables are read into memory and then written to the pagefile, but that seems inconsistent with my understanding.

So I don't understand enough of this issue to ask a good question, but I suspect it is something that needs clarification.

Great questions! If multiple process load the same DLL (like ntdll.dll), it isn’t efficient to load the file multiple times. Modern day operating systems load executable modules (exe or dll) in shared memory. The virtual page in each process where the module is loaded will point to the same shared section for the module. This way only one instance of the module is loaded. Each process will maintain its own private data (for globals and such) and use the shared pages for static and unmodified pages in the module. When the module’s pages are removed from working sets, the page is not committed to the page file. These pages are backed by the file on disk, so it doesn’t make sense to save a copy to the page file as well. Basically we remove the page from physical memory. A hard fault to one of these pages will be resolved from the file on disk. If a process modified module globals or data structures, those pages would be converted to private committed and would be backed by the page file.

Too Much Cache?

Noticias externas — Tue, 27 Nov 2007 19:48:51 GMT

Cache is used to reduce the performance impact when accessing data that resides on slower storage media

Too Much Cache?

Microsoft Advanced Windows Debugging and Troubleshooting — Tue, 27 Nov 2007 18:46:25 GMT

Cache is used to reduce the performance impact when accessing data that resides on slower storage media. 

re: The Memory Shell Game

Attila — Wed, 07 Nov 2007 00:19:17 GMT

If the the os gets hibernated, the standby pages are written to the hiberfil.sys?

re: The Memory Shell Game

Saurabh — Sun, 04 Nov 2007 17:19:25 GMT

Indeed, a very good article. Such a complex topic written in a very lucid elegant way...thanks so much.

re: The Memory Shell Game

A Santa Monica — Tue, 16 Oct 2007 22:20:15 GMT

Very good article.

Very good reference to Windows Internals as well.

Thank you for writing.

It might be a rather naive question but I would like to understand how it is implemented the hierarchical access time for those pools.

I mean, I suppose accessing the standby page´s pool 'takes lesser' then acessing free page´s pool or zeroed page´s pool and that acessing all the three pools 'takes longer' than accessing the pages on the working set.

Is it only because of the calls and context switching(efforts) that would take a process to request the memory manager to grab those pages(which are not on its working set space) or there are other reasons like the design of those particular pools(and here I am thinking of pools as queues and the different approaches one might implement for acessing queues and serializing/parallelizing access strategies).

See, I dont quite get it what makes the standy pages more quickly acessible in opposite to free pages or zeroed pages, for instance.

Since they are all on the same physical memory and no concepts such as NUMA are appliable.

Thank you once again.

[The access time for a page in the process’ working set will be the fastest. If a page leaves the process’ working set, it is placed on to the standby list. If a thread accesses the page when it is on the standby list, the thread will encounter a trivial delay. A page fault exception occurs and is handled by the memory manager. No context switch occurs for this operation. This soft fault will require some CPU cycles and a few access requests to physical RAM. The performance hit for this soft fault is so small; you will probably never notice it. I have only heard of one high performance application being affected by this, but I never saw any performance data to validate this claim. The application probably accessed its pages poorly and perhaps could have benefited from locking some of its critical pages into physical memory.

When a process requests a new page, transitioning from the zero page list will be the fastest. After that is transition from the free list to the zero page list. This transition requires a page scrub. This is bound by the speed and bandwidth of your physical RAM. There is no context switch here as well. Once again, these are very small performance hits. Chances are that you’ll never notice the hit from this operation. I hope this answers your questions.]