Recently, to future-proof my computer, I've added on top of my original 4GB of memory. I brought the total memory to 8GB, and I've got no noticeable change in speed– even when it should. I went to look into Task Manager and saw that my computer would NOT go over 4GB of memory being used, even with both Chrome and Firefox open with 20 tabs each.
After researching, everything that everyone had suggested to do was to check on how much memory was usable. Oddly enough, it says that I have 8GB of memory, and 7.74GB is usable.
The specs for my HP Pavilion g7-1075dx can be found here.
It is a notebook PC with Windows 7 Home Premium 64-bit with AMD Phenom II.
My main question is: with my 64-bit computer, why is my computer not using more than 4GB of memory, even when more than 7 is usable?
EDIT: if it helps, Resource Monitor describes all the other RAM as "Standby"
Best Answer
"Standby" RAM is in use. It's being used as a page cache (it holds pages recently lost from all process working sets; i.e. page faults to these can be resolved without going to disk) and also for proactive file cacheing by SuperFetch.
It's considered "available" because Standby pages don't have to be written to disk before they can be assigned to some other use. Such as when a process hits a page fault that does require reading from disk, new physical page(s) must be allocated to that process, and if necessary these can be taken from the Standby list. (This is not the first choice for finding pages for this purpose, that would be the free and then the zero page list.)
In other words your system is operating as it should be.
You can force your system to get more RAM into the "in use" state easily with the command-line tool
testlimit, one of the tools used in the experiments in Windows Internals. It is not part of the regular sysinternals tools but is associated with them; find it here at the sysinternals site. The download is a zip file that contains two versions, testlimit.exe and testlimit64.exe. Both are linked large-address-aware, so the 32-bit version will be able to allocate up to 3 GiB on a 32-bit machine booted with /3GB, up to 4 GiB on a 64-bit machine.c:\> testlimit -?gives help.c:\> testlimit -d 4 -c 512will attempt to allocate 2 GiB of process-private virtual address space in 512 allocations of 4 MiB each. This should work fine on a 64-bit machine. On a 32-bit machine not booted with /3GB (most are not) it may error a little earlier b/c there's already a few MiB of stuff in the process (like the program itself, all the DLLs, etc.), so there is not quite a full 2 GiB available for the program to allocate.In both cases there will be a reduction in "available" RAM, and an increase in "In use" RAM, but not necessarily 2 GiB worth because there is no guarantee that the OS will leave all 2 GiB in the process private working set. Even if it does that in the short term, you may see the process working set decrease later as the OS decides "hm, you're not really doing anything with it, other processes need it more" and pages it out.
Increase the size of the allocation "chunks" too much, reducing the number of chunks accordingly, and it will likely fail sooner as each allocation has to be virtually contiguous. e.g. try to find seven 512 MiB chunks in a 4 GiB address space and you'll likely fail.
If you use the l(eak) option instead of d(irty) the program will allocate the virtual space but will never reference it. This will not result in any appreciable decrease in "available" RAM.
(The d(irty) option takes its name from the "dirty page bit" in the x86/x64 page table entry, which is set when the corresponding virtual page is accessed with a "modify"-style operand, meaning the page's contents have been changed. This is Windows' indication that, should the page have to be evicted from the process working set, its contents have to be saved somewhere before the page can be used for something else. Pages with the "dirty" bit set go to the "modified page list" immediately after eviction; from there, Windows writes them to their respective backing stores.)
You will need to have sufficient "commit" available for these tests to work as described above (even for the l(eak) option, even though this option does not use any appreciable amount of RAM). Specifically, your "commit limit" should be at least 2 GiB (or however much you're allocating) higher than the "commit charge" before starting your test. Notice that this applies even if you're using the l(eak) option, not just d(irty). If you run into this limit you will see the "system is running low on memory" pop-ups or similar. The cure, of course, is to add more RAM and/or increase your pagefile settings.