1. Disablepagingexecutive: Changing this value to 1 "forces" Windows to keep the kernel in RAM and not page it to the pagefile. Pretty useless. Windows 7 is quite smart on this part. It keeps the kernel in RAM whenever possible automatically, no need to tweak -- and it's always there in the memory if you have plenty of it (4 gigs and above).
Actually not useless if you're debugging on x64, if you want to get callstacks with most debugging tools. Also, it keeps the kernel *executive* - drivers and system code that could normally be paged out - in memory. It's not quite the same as the whole kernel.
It does have dangers though - if the kernel executive is locked in memory and you have a system with heavy memory pressure, not being able to page this portion of the kernel out could result in a bugcheck, so you should only enable this when debugging. Not useless, but could be dangerous and only for use under specific scenarios. Also, memory pages that make up the kernel executive aren't likely to be paged out unless some of those pages go inactive for long periods, or there's memory pressure - this really isn't going to get you much of a performance benefit anyway.
2. Largesystemcache: Changing this value is known to bog/slow the system down. This tweak only helps in server environments, not for general users like us.
That depends - if the main use of the system is to load a lot of files (or fewer large files) into memory and manipulate them, this would definitely have a benefit in that specific scenario. That's not a common desktop scenario, but for those people doing development of large VS projects, or perhaps CAD or manufacturing work, this can actually benefit if the files that are loaded would continuously be accessed or reloaded over and over. It's specific, but it has it's uses. It is true this is more beneficial in a file server capacity on a server though.
As to the rest:
- NonPagedPoolQuota
This setting overrides the default dynamic value that any one process or driver can call to allocate from the kernel's nonpaged pool memory pool, and replaces it with a value (and the maximum size that can be set for max allocation differs between 32 and 64bit OSes). Given this is designed more for troubleshooting, or systems where nonpaged pool exhaustion may happen if not controlled (I've not ever in my life seen an x64 desktop come close to causing this before other issues occur as well, for what it's worth), it doesn't give you *any* performance gains by setting it. Also, because you're taking over for the memory manager when setting this, you should be *very* sure you're not causing issues by removing the dynamic nature of the nonpaged pool controls on Vista/2008 or higher systems....
- NonPagedPoolSize
Similar to the previous value, this setting is for configuring the maximum size of the kernel nonpaged pool that is allocated (in bytes, I believe) versus letting it be sized based on available RAM in the system during boot. I would argue that setting this outside of XP/2003 is no longer necessary (because the pools can dynamically grow or shrink based on system load), and setting it has no performance improvement implications either (just like the previous setting).
- PagedPoolQuota
See nonpagedpoolquota - this setting does the exact same, but for the kernel paged pool memory pool. As with setting a nonpagedpoolqouta value, it's really for tshooting or for systems where you already know and are trying to control paged pool memory resources. As with Vista/2008 and higher, given nonpaged pool and paged pool sizes can dynamically grow or shrink in the kernel memory region as necessary, this really is a relic of old thinking and old system designs and isn't necessary. Also, just like nonpagedpoolquota, there aren't performance implications with setting this either.
- PagedPoolSize
See nonpagedpoolsize.
- SessionViewSize
Setting this value to a value higher than the default allows for more memory to be allocated for desktop heap usage, but I would argue if you're running out of desktop heap you either have a poorly written application, or you already know what to set this size to (as determined by the application vendor who knows this is already going to be a problem). Again, there aren't performance benefits to setting this, but you could be reducing the amount of memory used in other kernel pool areas relating to the desktop and services - this isn't one you should play with unless you have good reason to, and the reasons would *not* be performance-related.
- SessionPoolSize
This memory is reserved for video driver allocations for drawing items on the desktop, and on 64bit systems the default for this value is already 64MB. As with setting the SessionViewSize, if you need to configure this it would be for a specific application that uses the GPU directly and would need more than the default 64MB for drawing items in an application on the desktop. Very specific setting, and does not affect performance (but may be required for specific applications that use the GPU directly to draw items on the desktop, usually within an app - I ran across a CAD app once that wanted 128MB here, but that was once in about 20 years).
- WriteWatch
This registry value died with Windows 2000 and hasn't been used since then (if you set it, it does nothing on XP/2003 and higher).
