Originally posted by: Matthias99
Originally posted by: xtknight
Originally posted by: beggerking
yes. . to address the lack of physical memory by indexing hd spaces to be used as physical memory.
No. To address ANY kind of memory. Physical memory does not need to be lacking for virtual memory to be in use.
Virtual Memory is always in use, even when the memory required by all running processes does not exceed the amount of RAM installed on the system.
Virtual memory maps a virtual code (which means NOTHING in terms of direct operation) to an address that points to the exact location the memory is to be read or written. When the data is paged out of the physical memory to the page file, the application can use the same virtual memory address, but the virtual memory will now be mapped to the page file instead, where less-accessed memory is stored. When the application is in use again, the memory is paged back out of the page file into physical memory where the application can access it faster. All throughout these processes the same virtual memory 'code' remains the same to redirect the application to whereever the data may be located.
Virtual memory is not the same as a page file or swap file, nor does it only contain addresses for page/swap files.
Thank you. Someone else actually understands what the hell I'm talking about.
Getting slightly back on topic:
Since I'm rebuilding my HTPC (which has a RADEON 9600 installed), and I hadn't installed the video drivers for it yet, I thought I'd take a look and see what happens to memory usage with Catalyst / CCC installed.
Without Catalyst/CCC or .NET installed, sitting at the desktop, my commit charge was about 115M, and the three kernel memory usage counts were about 27M/20M/6.8M.
After installing .NET 1.1/2.0:
Commit charge was around 120M, and the kernel memory usage was about the same.
After installing Catalyst 6.1 with CCC (just sitting at the desktop):
Commit charge jumped up to around 195K(!), and kernel memory usage was not about 34.5M/22.3M/12M. That's a pretty big jump, so I started looking at it more carefully.
With CCC actually open (which only took about three seconds the first time and maybe 1-2 seconds after that):
Commit charge went up to about 210M, with no change in kernel memory usage.
With the 3D preview window open:
Commit charge was about 230M.
Disabling the system tray icon cut the commit charge to ~185M with CCC closed, 190M with it open, and 210M with the preview window up. However, this still seemed high.
Following a tweak guide I found, I disabled the two ATI services and the 'CLI' program it starts up when your system boots (I also kept the system tray icon disabled).
Doing that dropped the commit charge to about 130M, with kernel memory usage of 30M/19M/11M. This seemed more in line with what the driver itself should use; disabling these services keeps it from loading CCC/.NET into memory when you start up the system.
At that point, starting up CCC took about 10-15 seconds, and bumped the commit charge up to the same point as before. When I closed CCC, commit charge dropped to about ~165M and stayed there (I'm guessing that some of the .NET stuff stays resident once it is loaded the first time). This would peg CCC (plus various .NET things it is using) at ~50-80MB of memory usage (with most of that difference being the 3D preview window), with the actual Catalyst drivers at somewhere around 10-20MB.
Now, 'Commit Charge' measures how much virtual memory has been allocated on behalf of various processes running in the system. While CCC by default sets aside a whole bunch of memory, it's not actively using those memory pages unless CCC is actually open. These pages will just get pushed out to the swapfile if there is not enough room in your physical memory, and it should not actually impact performance very much.
That said, an extra 80MB of memory usage just so you can load up CCC at a moment's notice seems a little excessive. It would be nice to have an easier way to disable this than having to manually turn off the ATI startup services.