This article discusses memory management issues such as working set size,nonpaged pool, and locking pages into physical memory via VirtualLock().
A process's working set is the set of pages that it has currently inmemory. The values for maximum working set and minimum working set arehard-coded in Windows NT and are thus impossible to change. There are threevalues hard-coded for the maximum working set. The value used for maximumworking set depends on whether your machine is considered to be a small,medium, or large machine:
Small machine--less than 16 megabytes (MB)
Medium machine--between 16 MB and 20 MB
Large machine--greater than 20 MB
The system tries to keep about 4 MB free to reduce the paging that occurswhen loading a new process, allocating memory, and so forth. Any free RAMbeyond what the system requires is available for the system to use toincrease your working set size if your process is doing a lot of paging.
Process pages that are paged out of your process space are moved into the"standby list," where they remain until sufficient free RAM is available,or until system memory is low and they need to be reused. If these pagesare accessed by your process while they are still on the standby list andmore RAM has become available, they will be "soft-faulted" back into theworking set. This does not require any disk access, so it is very quick.Therefore, even though you have an upper limit to the size of your workingset, you can still have quite a few process pages in memory that can bepulled back into your working set very quickly.
To minimize working set requirements and increase performance, use theWorking Set Tuner, WST.EXE, to order the functions within your code. Oneway to help an application receive a larger working set is to use theNetwork application in the Control Panel to set the server configuration to"Maximize Throughput for Network Applications."
System memory is divided into paged pool and nonpaged pool. Paged pool canbe paged to disk, whereas nonpaged pool is never paged to disk. In WindowsNT 3.1, the default amount of nonpaged pool also depends on whether yourmachine is considered small, medium, or large. In other words, you willhave X amount of nonpaged pool on a 16 MB machine, Y amount of nonpagedpool on a 20 MB machine, and Z amount of nonpaged pool on a machine withmore than 20 MB (the exact values for X, Y, and Z were not made public).
Important system data is stored in nonpaged pool. For example, each WindowsNT object created requires a block of nonpaged pool. In fact, it is theavailability of nonpaged pool that determines how many processes, threads,and other such objects can be created. The error that you will receive ifyou have too many object handles open is:
Many 3.1 applications ran into this error because of the limited amount ofnonpaged pool. This limit were addressed in Windows NT 3.5. We found that:
- Some objects were too large
- Sharing an object caused excessive quota charges
- The quota limits were artificial and fixed
The resources used by each object were evaluated and many were drasticallyreduced in Windows NT 3.5.
In Windows NT 3.1, every time an object was shared, quota was charged foreach shared instance. For example, if you opened a file inheritable andthen spawn a process and have it inherit your handle table, the quotacharged for the file object was double. Each handle pointing to an objectcost quota. Most applications experienced this problem. Under Windows NT3.5, quota is only charged once per object rather than once per handle.
Windows NT 3.1 had a fixed quota for paged and nonpaged pool. This wasdetermined by the system's memory size, or could be controlled by theregistry. The limits were artificial. This was due to the poor design ofquotas with respect to sharing. It was also affected by some objects lyingabout their actual resource usage. In any case, Windows NT 3.5 has revisedthis scheme.
The Windows NT 3.1 "Resource Kit, Volume I" documents that it is possibleto change the amount of nonpaged pool by modifying the following registryentry:
HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\ Control\ Session Manager\ Memory Management\ NonPagedPoolSize WARNING
: This modification can cause the system to crash, and thereforeMicrosoft does not recommend that this registry entry be changed.
Quotas can still be controlled in Windows NT 3.5 using these Windows NT 3.1registry values. However, this technique is now almost never needed. Thenew quota mechanism dynamically raises and lowers your quota limits as youbump into the limits. Before raising a limit, it coordinates this with thememory manager to make sure you can safely have your limit raised withoutusing up all of the systems resources.
To lock a particular page into memory so that it cannot be swapped out todisk, use VirtualLock(). The documentation for VirtualLock() states thefollowing:
Locking pages into memory may degrade the performance of the system by reducing the available RAM and forcing the system to swap out other critical pages to the paging file. There is a limit on the number of pages that can be locked: 30 pages. The limit is intentionally small to avoid severe performance degradation.
There is no way to raise this limit in Windows NT 3.1--it is fixed at 30pages (the size of your working set). The reason that you see a severeperformance degradation when an application locks these pages is thatWindows NT must reload all locked pages whenever there is a context switchto this application. Windows NT was designed to minimize page swapping, soit is often best to let the system handle swapping itself, unless you arewriting a device driver that needs immediate access to memory.
Windows NT 3.5 allows processes to increase their working set size by usingSetProcessWorkingSetSize(). This API is also useful to trim your minimumworking set size if you want to run many processes at once, because eachprocess has the default minimum working set size reserved, no matter howsmall the process actually is. The limit of 30 pages does not apply toVirtualLock() when using SetProcessWorkingSetSize().