OK, there's a lot of misunderstanding going on here and I'm going to try and clear things up as much as possible.
To start:
1) I'm a GPU driver architect. I do this sort of thing for a living. I don't work for NV or AMD, but for a little British IP company in Cambridge whose products all of you on this forum use.
2) I could be wrong so please educate me if you think I am
3) I'm not familiar with BF3... not played it yet.
OK here goes:
1) A user space process (such as BF3) can't control how paging is handled directly on Windows. As far as I know, an application can hint on the 'pageability' of memory it allocates, but can't forcibly page memory. What I'm saying is that the page file is handled by the OS, and the user space process only sees memory without knowing whether it is paged or not -- this seamlessness is part of the OS's mandate.
2) If you have enough memory there is very little reason to have a page file. Some processes use the page file for heuristic based memory allocations, but otherwise it isn't needed. Without a page file, however, if you run out of memory you will have processes' memory requests denied causing all kinds of issues. Most code will simply bug out if a memory request fails since often there is no error path that can recover from such an issue. So maybe your torrent client called malloc for the next piece of a file and this resulted in BF3's next allocation returning NULL...
3) BF3 might be using more VRAM than it needs. Just like Windows caches portions of the filesystem and so on in system RAM, BF3 might be caching textures that it might need in the future to prevent it needing to load it via memory. This is a form of lazy flushing -- why spend time deallocating memory when you might need it later? Just deallocate when you need the space...
4) If BF3 had to halt and wait for memory to come back from the page file via a disk access, your framerates would be effectively 0. Once the data is in VRAM, however, your framerates will be back up again. Compare memory bandwidth of VRAM/RAM and a HDD/SSD to see what I mean. If games are running into VRAM bandwidth issues at around 190GB/s imagine what happens when you rely on something only as fast as 6GB/s (SATA 3 theoretical max)... Not to mention all the layers it needs to go through to get to your VRAM (SSD -> South Bridge -> Memory -> PCIX -> GPU).
Although I think Andy's assumptions are wrong and stem from a misunderstanding of how these aspects of drivers/OSs work, I commend him for taking the time to write a post with some figures and incite and interesting discussion. There's no need to start flaming each other, we're all gamers after all, aren't we?