Does the DisablePagingExecutive registry change have any actual effect?
Solution 1:
There is an enormous amount of confusion on the internet regarding this function. The setting effects only a portion of the kernel known as the executive, and then only to the portions that are pageable. There are other parts of the kernel that are completely unaffected by this setting.
Kernel paging works the same way as any other paging. Code and data that is frequently accessed will be kept in RAM while the remainder will remain on disk - where it belongs. The system will not remove any portion of the kernel from RAM unless it has found a better use for it. Microsoft has devoted an enormous amount of research and testing to the paging systems.
In the context of the kernel "Nonpaged" means code and data that can never be paged out under any circumstances. "Paged" means code and data that CAN be paged out if necessary. How much actually IS paged out is impossible to tell from Task Manager. A portion of the code that is paged out was never read from disk in the first place because it wasn't needed yet. Not all of the kernel is frequently accessed. You should not expect Paged and Nonpaged numbers to be effected by the setting in question.
Note: When code is paged out it is not normally copied to the pagefile. This is not necessary as it can simply be reloaded from the original files. This applies to most code, not just the kerenl.
With a reasonable amount of RAM the setting will do essentially nothing. It simply prevents the system from paging out data that it didn't want to page out anyway.
Solution 2:
I'm not sure if you realise this, but page-faults are the mechanism which Windows uses to load executable code. So, for example, a DLL is mapped to virtual memory, and then page-faults are used to do the actual loading from disk as required. The pagefile is not involved in this.
So lots of what you think of as 'paged to disk' might be stuff that was on disk in the first place.
Solution 3:
Just to add one additional use of this setting: it is needed by xperf stack walking.
http://blogs.msdn.com/b/pigscanfly/archive/2009/08/06/stack-walking-in-xperf.aspx
Disable Paging Executive
In order for tracing to work on 64-bit Windows you need to set the DisablePagingExecutive registry key. This tells the operating system not to page kernel mode drivers and system code to disk, which is a prerequisite for getting 64-bit call stacks using xperf, because 64-bit stack walking depends on metadata in the executable images, and in some situations the xperf stack walk code is not allowed to touch paged out pages.
One additional piece of info about the setting. This quote can be found over the internet, I do not know its primary source.
DisablePagingExecutive applies only to ntoskrnl.exe. It does not apply to win32k.sys (much larger than ntoskrnl.exe!), the pageable portions of other drivers, the paged pool and of course the file system cache. All of which live in kernel address space and are paged to disk. On low memory systems this can force application code to be needlessly paged and reduce performance. 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. This setting is useful when debugging drivers and generally recommended for use only on servers running a limited well-known set of applications
So one can conclude that besides the xperf-usage its benefit is obscure: Essentially it limits some "almost random" stuff from paging and on further thought - consequently causes something else to be paged out more often instead.
Solution 4:
The DisablePagingExecutive tweak does not stop paging, it's purpose was to prevent the "Executive" (i.e. the Kernel itself) being paged and thus causing whole system slowdown, not just individual paged apps.
You can try and disable paging completely by removing all pagefiles in System Properties (or in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles). This works well for me, but things get rather unpleasant when you run out of physical memory, and you must have a page file to debug STOP errors.