I am the author of the text quoted from tweakxp.com , in the thread "Errors in "Tweaking Windows XP" guides", that ends with:
"If you still don't believe it, try running MarkR's "regmon" tool, starting at boot time, logging all registry accesses to a file. Search the resulting log for references to DisablePagingExecutive and LargeSystemCache, which you will find, and for IoPageLockLimit, which you won't as of win2k sp1."
I would have replied in that thread, but the moderator locked it. It is arguable whether the tone of the discussion in that thread merited locking, but there is just no ambiguity about the facts here: The IoPageLockLimit value is ignored as of Win2K SP1. Nothing and nobody reads it in Win2K SP1, Win2K SP2, or WinXP. Ever. The system doesn't even know that name any more. Something you can prove for yourself with the methods I described.
The fact that heinz57 says "I use [it] set to 32 works great" means nothing. (If actually interpreted that way that would mean 32 BYTES, a ridiculously small number.) You could create a registry value called "MaryHadALittleLamb" and stuff it into this key and your system would "work great". Does that mean the system is using your new registry value? No.
By the way, default and minimum values for IoPageLockLimit were always 512Kbytes. (K=1024 here.) So even under Win2K RTM, where the value actually is read, if you put a value smaller than 524288 in there, the system would just say "whups, too small" and set the value used internally to 524288. About half of the tweak sites I've seen recommend values smaller than this (sometimes further misstating that the value should be spec'd in KB, resulting in an even smaller number in the registry). Result, the system would just use its minimum of 512KB, so all those tweaks did essentially nothing even though the system WAS reading the value.
Also, on those versions where it does work, it's important to understand that IoPageLockLimit does not reserve any memory. It's a system-wide quota, allowing the indicated amount of RAM to be "locked" against paging ("pinned" is the term used in some contexts) for the support of, and only for the duration of, currently-pending direct IO operations. "Direct IO" is a system mechanism most commonly used when the hardware is doing DMA. The purpose of "pinning" a buffer is to make sure it doesn't get paged out, and hence moved, in physical memory once a DMA controller has been given its physical address. But once the DMA operation is done, the buffer is unlocked (unpinned).
So, the default value of 512Kbytes essentially says that you can have 512Kbytes worth of buffers for DMA transfers pinned into RAM at one time. Given that the typical disk IO transfer size is 64 Kbytes, this allows eight such transfers at a time. Now most systems only have one IDE hard drive, and perhaps a CD-ROM, and an IDE controller can only be performing one transfer at a time... so the most you'd ever likely use of this quota is 128 Kbytes. However, since this value does not represent a permanent reservation of RAM -- it simply allows the system to temporarily lock up to the indicated amount of RAM -- setting it to larger than will be used won't hurt.
While I'm here:
Setting "DisablePagingExecutive" to 1 does not "deactivate memory paging", and it does not disable the "paging executive". (There is nothing in the system that is called the "paging executive.") It disables the paging OF the executive, which is to say most of ntoskrnl.exe, and some (not all) of the other pageable stuff in system address space. (A notable exception is the file system cache, i.e. paging of the file cache is NOT disabled by this value.)
If you have more than enough RAM for your workload, yes, this won't hurt, but then again, if you have more than enough RAM for your workload, the system isn't paging very much of that stuff anyway.
Think of it this way: For a given amount of demand for RAM + a given amount of RAM, there will be a certain amount of paging. DisablePagingExecutive says "don't page the OS code or some of its data". But for given demand + amount of RAM, there has to be a certain amount of paging, so the result is that app code and data will be paged MORE. It's a tradeoff. The usual rationale for this tradeoff is that the system's code is used by all the apps, so it's better to keep the system's code in memory and let the apps page. Sometimes it is.
By the way, you can never disable paging completely in this OS family. This is a virtual memory OS. Even removing the paging file won't disable paging -- the paging file is by far not the only file involved in paging. You'll just make it page to other files more.
LargeSystemCache: The explanation for this one in the tweak guide is off the wall in more than a few ways. Briefly, this setting simply allows the system's working set (which includes the file system cache) to use proportionally more of physical memory, in relation to process working sets, than it otherwise would.
It does not allow the file cache to use all but 4MB (4MB wouldn't be nearly enough for everything else that needs to be in RAM), and there is no "disk cacheing" that is used by the "4MB of memory left" (there is no "disk cache" in the NT family at all, only a file cache, and there isn't just 4MB of memory "left" in this case anyway).
Where the "4MB" figure does come in is that LargeSystemCache also allows the "available" physical memory to drop well below 4 MB before the system begins aggressive memory reclamation; normally it does this at the 4 MB threshold. The result here is that if you have a stable applications mix (like on a server) that is mostly doing the same thing over and over, setting LargeSystemCache to 1 allows a bit more stuff to be kept in RAM. The tradeoff is that there will be very little free RAM available to support the paging in of new code or data.. so when that happens, some other stuff will have to be paged out. In other words, if you are short on RAM and you are doing a lot of startups of new apps, setting LargeSystemCache to 1 will probably not be a good idea. On the other hand, if you have plenty of RAM, it probably won't matter either way.
"If you still don't believe it, try running MarkR's "regmon" tool, starting at boot time, logging all registry accesses to a file. Search the resulting log for references to DisablePagingExecutive and LargeSystemCache, which you will find, and for IoPageLockLimit, which you won't as of win2k sp1."
I would have replied in that thread, but the moderator locked it. It is arguable whether the tone of the discussion in that thread merited locking, but there is just no ambiguity about the facts here: The IoPageLockLimit value is ignored as of Win2K SP1. Nothing and nobody reads it in Win2K SP1, Win2K SP2, or WinXP. Ever. The system doesn't even know that name any more. Something you can prove for yourself with the methods I described.
The fact that heinz57 says "I use [it] set to 32 works great" means nothing. (If actually interpreted that way that would mean 32 BYTES, a ridiculously small number.) You could create a registry value called "MaryHadALittleLamb" and stuff it into this key and your system would "work great". Does that mean the system is using your new registry value? No.
By the way, default and minimum values for IoPageLockLimit were always 512Kbytes. (K=1024 here.) So even under Win2K RTM, where the value actually is read, if you put a value smaller than 524288 in there, the system would just say "whups, too small" and set the value used internally to 524288. About half of the tweak sites I've seen recommend values smaller than this (sometimes further misstating that the value should be spec'd in KB, resulting in an even smaller number in the registry). Result, the system would just use its minimum of 512KB, so all those tweaks did essentially nothing even though the system WAS reading the value.
Also, on those versions where it does work, it's important to understand that IoPageLockLimit does not reserve any memory. It's a system-wide quota, allowing the indicated amount of RAM to be "locked" against paging ("pinned" is the term used in some contexts) for the support of, and only for the duration of, currently-pending direct IO operations. "Direct IO" is a system mechanism most commonly used when the hardware is doing DMA. The purpose of "pinning" a buffer is to make sure it doesn't get paged out, and hence moved, in physical memory once a DMA controller has been given its physical address. But once the DMA operation is done, the buffer is unlocked (unpinned).
So, the default value of 512Kbytes essentially says that you can have 512Kbytes worth of buffers for DMA transfers pinned into RAM at one time. Given that the typical disk IO transfer size is 64 Kbytes, this allows eight such transfers at a time. Now most systems only have one IDE hard drive, and perhaps a CD-ROM, and an IDE controller can only be performing one transfer at a time... so the most you'd ever likely use of this quota is 128 Kbytes. However, since this value does not represent a permanent reservation of RAM -- it simply allows the system to temporarily lock up to the indicated amount of RAM -- setting it to larger than will be used won't hurt.
While I'm here:
Setting "DisablePagingExecutive" to 1 does not "deactivate memory paging", and it does not disable the "paging executive". (There is nothing in the system that is called the "paging executive.") It disables the paging OF the executive, which is to say most of ntoskrnl.exe, and some (not all) of the other pageable stuff in system address space. (A notable exception is the file system cache, i.e. paging of the file cache is NOT disabled by this value.)
If you have more than enough RAM for your workload, yes, this won't hurt, but then again, if you have more than enough RAM for your workload, the system isn't paging very much of that stuff anyway.
Think of it this way: For a given amount of demand for RAM + a given amount of RAM, there will be a certain amount of paging. DisablePagingExecutive says "don't page the OS code or some of its data". But for given demand + amount of RAM, there has to be a certain amount of paging, so the result is that app code and data will be paged MORE. It's a tradeoff. The usual rationale for this tradeoff is that the system's code is used by all the apps, so it's better to keep the system's code in memory and let the apps page. Sometimes it is.
By the way, you can never disable paging completely in this OS family. This is a virtual memory OS. Even removing the paging file won't disable paging -- the paging file is by far not the only file involved in paging. You'll just make it page to other files more.
LargeSystemCache: The explanation for this one in the tweak guide is off the wall in more than a few ways. Briefly, this setting simply allows the system's working set (which includes the file system cache) to use proportionally more of physical memory, in relation to process working sets, than it otherwise would.
It does not allow the file cache to use all but 4MB (4MB wouldn't be nearly enough for everything else that needs to be in RAM), and there is no "disk cacheing" that is used by the "4MB of memory left" (there is no "disk cache" in the NT family at all, only a file cache, and there isn't just 4MB of memory "left" in this case anyway).
Where the "4MB" figure does come in is that LargeSystemCache also allows the "available" physical memory to drop well below 4 MB before the system begins aggressive memory reclamation; normally it does this at the 4 MB threshold. The result here is that if you have a stable applications mix (like on a server) that is mostly doing the same thing over and over, setting LargeSystemCache to 1 allows a bit more stuff to be kept in RAM. The tradeoff is that there will be very little free RAM available to support the paging in of new code or data.. so when that happens, some other stuff will have to be paged out. In other words, if you are short on RAM and you are doing a lot of startups of new apps, setting LargeSystemCache to 1 will probably not be a good idea. On the other hand, if you have plenty of RAM, it probably won't matter either way.
Comment