SSD as boot drive question

Serephucus wrote: »

That's what I thought, but apparently I was wrong. That was how it worked in the XP days, but apparently Vista/7 implement virtual memory differently. Part of it is always used, whether it's needed or not, meaning your memory is only ever as fast as your hard drive.

Also, I have 6GB. Even with Media Player, WLM, Skype, Dropbox, Sidebar, thirty or so FF tabs, a heavily modded Star Trek Bridge Commander, UT3, and Crysis running, I was at 5.1.

I started off to make a quick reply, but got a little carried away (Also off topic so sorry OP )

With with 6Gb you are sorted anyway :pac:, although in general I really don't think there is much of a performance difference between an enabled and disabled paging file. Depending on your usage patterns and amount of Ram etc it may work out better for some and worse for others. As you have never had a problem of course theres is no need to change anything.

The main point I wanted to make is that Windows 7(and Vista) memory management is really quite sophisticated and works in broadly the same manner whether you are using a pagefile or not.

It essentially operates by the creed 'Empty Ram = wasted RAM'. and actively tries to keep your RAM as full as possible at all times (It does not appear full in Task manager, why will become clear in a minute)

While the full story is more complicated (And way beyond my knowledge level) Win 7 RAM usage can be roughly broken down into 6 basic parts Kernel memory (pageable and non pageable), the Process Working Set, the Standby list, the modified List, the zero page list and the free page list.

• Kernal memory (not really a correct or fully accurate term, but it will suffice for the purpose of this post) contains system related memory pages some of which are non pageable (critical parts that cannot ever be moved out of physical memory) and some of which are pagable (Can be moved out of RAM out like any normal process).
  
  
• The Process Working Set contains all the active memory pages in use at the moment by various application (some of this is shared and some of this private to individual processes)
  
  
• The Standby lists contain unmodified pages which are no longer in the active working set of a process and have been made available for use by other processes if required, but the contents are still stored in physical RAM, which effectively makes the Standby list a RAM cache (AFAIK this is also where Superfetch loads to when enabled).
  
  
• The Modified page list contains pages that have been modified but not yet saved back to disk by the owning process, when these pages have not been accessed for some time they are also removed from the process working set.
  
  
• The Zero page list contains pages that have been initialized to zero, ready for use when the memory manager needs a brand new page.
  
  
• The Free page list tracks memory pages that were previously allocated and returned to the memory manager for reuse (such as by a process closing). These ultimately get put back on the zero page list as required.

Kernel memory and working set make up the currently 'In Use' Ram, however sometimes the memory manager must 'trim' the working set of a process (or pageable kernel memory) for a number of reasons such as the the process reaching it memory limit, or has become inactive for some reason. During trimming pages deemed less likely to be used are moved out of the working set.

Regardless of whether or not you have a pagefile or not, these trimmed pages go to either the standby list if unmodified, or the modified list if they have been written to (Both lists are still on physical memory). Pages in the modified list are usually copied out to the pagefile and then moved to the standby list making them available for use by any process again.

Pages can remain in the Standby list for a very long time as they are generally not removed unless that memory is needed for some other process. One of the main benefits of this approach is that it the process subsequently goes looking for a page after it has been trimmed from the working set, then unless RAM is running low it is very likely that it will still exist in the standby cache. This is known as a 'soft' page fault because the page only has to be restored from RAM, not disk, this is the main type of page fault in a system.

The free page list consist of unallocated memory or previously allocated memory that has been returned to the memory manager. Pages from here ultimately get zeroed and moved to the zero page list for when the manager required new pages. It is only if a process goes looking for a page that is now on the free or zero page list (or not in memory at all) that a 'hard' page fault will be generated and a disk read will be required.

When the memory manager needs memory it goes looking for it in this order, zero page list -> free list -> standby list -> working sets, so it is only if no other free memory is available that the standby list gets raided. (There are actually three priority levels that make up the standby list, the lowest rung of are for pages preloaded by the likes of superfetch if enabled, which will get reclaimed if needed by the memory manager before any pages on the standby list that belong(ed) to currently running process)

The reason why I don't believe disabling the pagefile gives much of give a performance boost is because RAM is always nearly full regardless as a result of this approach.

Here is a very rough breakdown of what is on my RAM at the moment, I have 4GB or Ram and am also using a 4GB pagefile (Using Perfmon tool) .I have rounded off a little so it doesn't exactly add up to to 4Gb

In Use
Process Working Set - 1.3 Gb
System memory (paged + unpaged) - 300Mb

Available
Standby List - 2.1+ GB
Modified Page list - 45MB
Free + Zero list 200 MB

Despite the memory being reported as having roughly 2.3-2.4 GB available (standby + Free + Zero + modified), you can see the I have only 200MB of genuinely unused RAM on on the free and zero list, and a little over half of my RAM is being used by the standby list as a cache. Out of curiousity have also been monitoring Page Reads using Perfmon (these are caused by 'hard' page faults) over the course of the evening and have had exactly zero thus far.

Technically with no pagefile you may even be reducing your useable ram slightly, because with a pagefile enabled, pages on the modified list are usually paged out to the pagefile for later writing to disk. However without a page file these must remain on the modified list indefinately (until saved and written to disk) , as they have nowhere else to go and may be blocking RAM from process that may have a more pressing need. For users with large amount of RAM this is not a problem as it is.

If anyone has actually got as far as this sentence, congratulations for not dying of boredom.