Pagefile on a RAMdisk

[Psychosomatic]

There are several 32bit apps (games) that I would like to optimize by loading their paged memory into a RAMdisk (ie, 2gb in memory, 4gb paged in RAMdisk). These games will fully utilize all 6gb combined that the OS will offer them, and I'd like it all to run at its fastest.

Is there any way in Win 7 Pro to define pagefiles across multiple disks, and then specify which applications can use each, or do all of the pagefiles just go into a shared pool that gets assigned randomly? Basically, I'd like to split off my RAM into 8gb of physical memory and 4gb in a RAMdisk to be used as a pagefile exclusively for these games, with an additional pagefile for general system usage on one of my harddrives.

If this isn't possible, what is my next best option for speeding up the paged memory? (Note: I already have a SSD for the large game files, but I will not be placing a pagefile on it)

 

[Idontcare]

Are you truly interested in paging out the game or are you really interested in creating a ramdrive to which you install the game?

If any portion of the game was "pageable" and it was this paging that you want to speed up and you are sure you have ample ram then I'd personally just disable paging altogether and that way you are ensured all the ram-loadable infos stay in the ram.

 

[SunnyD]

No.

 

[Nothinman]

There are several 32bit apps (games) that I would like to optimize by loading their paged memory into a RAMdisk (ie, 2gb in memory, 4gb paged in RAMdisk). These games will fully utilize all 6gb combined that the OS will offer them, and I'd like it all to run at its fastest.

A 32-bit process will never get more than 3G of memory because the highest upper limit of it's VM will be 4G and the kernel uses part of that for itself. The split is normally 2/2 but you can change it to 3/1 if you really want to deal with the problems that might create. There are ways to work around that with AWE but the app has to be written for that and I doubt your games are.

Is there any way in Win 7 Pro to define pagefiles across multiple disks, and then specify which applications can use each, or do all of the pagefiles just go into a shared pool that gets assigned randomly?

It's not random, Windows uses the one currently on the disk with the least I/O going on at the moment.

Basically, I'd like to split off my RAM into 8gb of physical memory and 4gb in a RAMdisk to be used as a pagefile exclusively for these games, with an additional pagefile for general system usage on one of my harddrives.

Which isn't possible and you're way, way, way over-thinking this without understanding how VM really works.

If this isn't possible, what is my next best option for speeding up the paged memory? (Note: I already have a SSD for the large game files, but I will not be placing a pagefile on it)

If you're actually using enough memory to hit the pagefile then you really should be leaving the pagefile on an SSD. Anything else is duct tape and bubble gum at best.

 

[Psychosomatic]

A 32-bit process will never get more than 3G of memory because the highest upper limit of it's VM will be 4G and the kernel uses part of that for itself. The split is normally 2/2 but you can change it to 3/1 if you really want to deal with the problems that might create. There are ways to work around that with AWE but the app has to be written for that and I doubt your games are.

While I am aware of the 4G limit for a 32-bit OS, I'm working with a 64-bit OS and 32-bit apps. It is my current understanding that a 32-bit app in a 64-bit environment can address up to 2G of memory (combined physical/virtual) without large-address aware, and up to 2G physical 4G virtual with, and it's this latter case that I'm trying to improve. However, I may be mistaken in the nature of these restrictions.

If you're actually using enough memory to hit the pagefile then you really should be leaving the pagefile on an SSD. Anything else is duct tape and bubble gum at best.

Leaving the pagefile on an SSD sounds like a good way to ensure that my drive dies well before its time, no thank you.

 

[FishAk]

IF you have a GOOD SSD, it's ideally suited for your page file- provided it has enough room.



If you already have a RAM disk, you can tell W7 to use it, and only it, for all paging. W7 will decide on it's own if and when it's best to swap out a page, but it's perfectly happy letting you tell it the exact location.


If you don't already have a RAM disk- don't get one. For the price, an SSD is better.

 

[Nothinman]

While I am aware of the 4G limit for a 32-bit OS, I'm working with a 64-bit OS and 32-bit apps. It is my current understanding that a 32-bit app in a 64-bit environment can address up to 2G of memory (combined physical/virtual) without large-address aware, and up to 2G physical 4G virtual with, and it's this latter case that I'm trying to improve. However, I may be mistaken in the nature of these restrictions.

Technically there's no such thing as combined virtual/physical memory. The amount of virtual memory any process can address is static depending on the configuration and that's it. Physical memory gets mapped into the virtual range so if your process can address 4G of virtual memory, that's all it can address.

4G of VM is the ceiling of a 32-bit app regardless of anything else. Since physical memory is mapped to virtual addresses, even with the LargeAddressAware switch enabled on a binary you'll be limited to 4G of physical or virtual. And since the binary itself, support libraries, mmap'd files, etc take up some of that virtual space the most any 32-bit app will be able to use is just under 4G.

Leaving the pagefile on an SSD sounds like a good way to ensure that my drive dies well before its time, no thank you.

Well besides getting more memory that's your only real option if pagefile usage is a problem.

If you already have a RAM disk, you can tell W7 to use it, and only it, for all paging. W7 will decide on it's own if and when it's best to swap out a page, but it's perfectly happy letting you tell it the exact location.

No, using a ramdisk for the pagefile is retarded. Do the right thing and get more memory and you won't need to use the pagefile.

 

[FishAk]

There's no doubt that adding memory is the best solution to paging. But, if additional memory isn't a viable option, and you already have a RAM disk, than setting the page file to it will retard the system significantly less than setting it to a spinning drive.


If you're not going to buy additional memory, and you already have the RAM disk, I see no reason not to use it for swapping. Performance wise, if you must page, the RAM disk may be faster than the SSD. I certainly don't see how it could hurt in this case.

 

[deimos3428]

Are you truly interested in paging out the game or are you really interested in creating a ramdrive to which you install the game?

If any portion of the game was "pageable" and it was this paging that you want to speed up and you are sure you have ample ram then I'd personally just disable paging altogether and that way you are ensured all the ram-loadable infos stay in the ram.

This. As an academic exercise, you can put a pagefile on a ramdisk. It will work, and it will be somewhat faster than paging to a hard disk, but it will still be slower than just using the memory as memory.

 

[Nothinman]

There's no doubt that adding memory is the best solution to paging. But, if additional memory isn't a viable option, and you already have a RAM disk, than setting the page file to it will retard the system significantly less than setting it to a spinning drive.


If you're not going to buy additional memory, and you already have the RAM disk, I see no reason not to use it for swapping. Performance wise, if you must page, the RAM disk may be faster than the SSD. I certainly don't see how it could hurt in this case.

If you're talking about one of those hardware ramdisks that is essentially a couple of sticks of memory on a PCI card, then sure that's not terrible. Not entirely smart either, but not terrible. But if you're talking about a software ramdisk that steals part of your main memory, that's 100% retarded.

 

[hanspeter]

The guys are telling you that

application > physcial memory

is faster than

application > page file in memory > physical memory

and you will force Windows to do the latter much more by reducing the amount of available memory.

 

[Voo]

Leaving the pagefile on an SSD sounds like a good way to ensure that my drive dies well before its time, no thank you.

If you're not planning to use a small SSD (<= 80gb) for 5+years - and who would? - then that's completely unimportant. The only possibility to kill a MLC SSD in that time is to put a heavy IO db or something alike on it.

Nothinman is completely correct with his explanations, not much to add there. A 32bit process can't access more than 4gb logical address space (or to be precise.. 4gb byte addressable memory) so that's the upper limit for the physical memory, no pagefile will change anything on that. So there's just no use case where a pagefile on a ramdisk would help, you get more administrative overhead (bad, bad kernel calls) without any advantage.

 

[MagickMan]

Leaving the pagefile on an SSD sounds like a good way to ensure that my drive dies well before its time, no thank you.

Not this crap again. D:

No decent MLC drive is going to "die before it's time" due to wear in a normal PC. Install the drive, leave all the MS set defaults alone, and forget about it. Just make sure defrag is off and you're golden.

 

[FishAk]

Oops- I didn't know you could get a Software Ram disk. Forcing the OS to page to the system memory when it runs out of memory, is among the dumbest circles I can think of.


Doesn't the electron trap leek over time? Than I would think, even “static” data must be moved from time to time, whenever the controller thinks it needs to refresh the traps. Weather you use or don't use your SSD, it still only has so much life, so don't worry so much about paging to it. Say you paid $300 for your SSD, and with normal use, it lasts 5 years. That's like five bucks a month- I mean, come on! These things are disposable! Can you even get a six-pack for 5 bucks?

 

[Nothinman]

Oops- I didn't know you could get a Software Ram disk. Forcing the OS to page to the system memory when it runs out of memory, is among the dumbest circles I can think of.

Exactly. And despite that little bit of common sense people continually try doing it.

 

[Idontcare]

Oops- I didn't know you could get a Software Ram disk. Forcing the OS to page to the system memory when it runs out of memory, is among the dumbest circles I can think of.

Exactly. And despite that little bit of common sense people continually try doing it.

When I had XP Pro 32bit I installed 8GB ram (it was dirt cheap at the time) and superspeed ramdisk that enabled me to make a ramdisk using the ram above the 3.25GB limit that XP couldn't access.

(superspeed refers to this feature as their "extended memory access" and it does work as advertised)

So XP had 3.25GB to play with and I got a nice zippy 5.75GB ramdisk to play with.

Then I set XP's pagefile to use the ramdisk.

 

[Nothinman]

When I had XP Pro 32bit I installed 8GB ram (it was dirt cheap at the time) and superspeed ramdisk that enabled me to make a ramdisk using the ram above the 3.25GB limit that XP couldn't access.

(superspeed refers to this feature as their "extended memory access" and it does work as advertised)

So XP had 3.25GB to play with and I got a nice zippy 5.75GB ramdisk to play with.

Then I set XP's pagefile to use the ramdisk.

And your fail can be summed up with the first and last sentences of your post. Use an OS that will actually let you use all of your hardware and you won't have that problem.

 

[Idontcare]

And your fail can be summed up with the first and last sentences of your post. Use an OS that will actually let you use all of your hardware and you won't have that problem.

My fail? I didn't have a problem, I had a set of boundary conditions and I sought to maximize my benefits from them.

Your ignorance of my boundary conditions is assured as you've not taken the time to inquire about them.

But your arrogance is quite prominently on display in that post.

Arrogance combined with ignorance...now that's fail :thumbsup:

 

[Voo]

And your fail can be summed up with the first and last sentences of your post. Use an OS that will actually let you use all of your hardware and you won't have that problem.

Apart from the useless tipp (use another OS? yep great, especially since he's talking about the past and we all know how stellar XP64 was - and I really do hope your imagined solution wasn't "just use Linux/Unix"..), as long as you don't know the circumstances you can't say anything about that.

In the first case it's obvious because we know what the original poster wanted to achieve, but if IDCs wanted to get better performance while multitasking (i.e. several different processes trying to use <= 2gb memory), that'd obviously bring performance improvements without a real drawback, so why not?

 

[Nothinman]

My fail? I didn't have a problem, I had a set of boundary conditions and I sought to maximize my benefits from them.

You bought hardware that you knew the OS you were using didn't support, I call that a fail.

Apart from the useless tipp

Making sure you can actually use a piece of hardware before you buy it is a useless tip?

 

[Voo]

Making sure you can actually use a piece of hardware before you buy it is a useless tip?

It is useless because we all know how great support for XP64 was back then, you couldn't even get working drivers for rather new hardware in many cases, not to forget that XP64 itself was a rather crude hack.

So you say he should either use a OS which probably didn't work well or at all with his hardware/programs or just use 3.5gb RAM although with his setup he got the advantage of 8gb RAM without any major drawbacks - except the 2/3gb constraint/program of which he was obviously aware and wasn't that much a problem? Yeah I don't really see the major insight in that. Today with good 64bit support everywhere? Sure why would anyone do that, but back then? Not even major GPU drivers worked well with XP64 (oh and we really should stay away of 64bit linux around 2002, that cost me more nerves than anything else).

 

[Nothinman]

It is useless because we all know how great support for XP64 was back then, you couldn't even get working drivers for rather new hardware in many cases, not to forget that XP64 itself was a rather crude hack.

It's not useless because 64-bit Vista has been out since like 2006, so unless he bought that 8G of memory between 2003 and then he had more options than just XP.

And it wasn't a crude hack, it was just a consumer build of Win2K3. All of the issues I know of are related to lack of drivers which isn't MS' fault. I wouldn't really recommend anyone use XP64, especially now, but if you have drivers for everything it'll work pretty much as well as 64-bit Vista or Win7.

So you say he should either use a OS which probably didn't work well or at all with his hardware/programs or just use 3.5gb RAM although with his setup he got the advantage of 8gb RAM without any major drawbacks - except the 2/3gb constraint/program of which he was obviously aware and wasn't that much a problem? Yeah I don't really see the major insight in that. Today with good 64bit support everywhere? Sure why would anyone do that, but back then? Not even major GPU drivers worked well with XP64 (oh and we really should stay away of 64bit linux around 2002, that cost me more nerves than anything else).

Back when? He never gave a time frame.

 

[zerogear]

http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx

Should the pagefile be placed on SSDs?

Yes. Most pagefile operations are small random reads or larger sequential writes, both of which are types of operations that SSDs handle well.

In looking at telemetry data from thousands of traces and focusing on pagefile reads and writes, we find that

* Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1,
* Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB.
* Pagefile.sys writes are relatively large, with 62% greater than or equal to 128 KB and 45% being exactly 1 MB in size.

In fact, given typical pagefile reference patterns and the favorable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD.

 

[Voo]

It's not useless because 64-bit Vista has been out since like 2006, so unless he bought that 8G of memory between 2003 and then he had more options than just XP.

Well I've got lots of hardware that wouldn't work with Vista 64bit for a long time as well and if I remember back, I'm positive I wasn't the only one with that. Got better with time, so yes around 2007 it was the better option at least if your hardware/software finally supported it, but that's exactly the problem: He didn't mention WHEN it was, so I assume he had no real alternative but XP.
At least if you can assume he did that after 06 and his hw/sw already supported it, then I can assume the contrary.. in dubio pro reo

And it wasn't a crude hack, it was just a consumer build of Win2K3. All of the issues I know of are related to lack of drivers which isn't MS' fault. I wouldn't really recommend anyone use XP64, especially now, but if you have drivers for everything it'll work pretty much as well as 64-bit Vista or Win7.

Yeah surely the drivers were the biggest problems (and most vendors didn't even get it right for Vista..), but it was still a server OS with some compromises.

 

[nk215]

I did the same thing for over a year (with 6 gig instead of 8) and everything worked fine (and fast). My reasons were simple, I didn't have a 64bit disks on hand at the moment and didn't want to reinstall my applications/games.

Now, even with a 64bit and a SSD (intel 160G2), I would do the samething if I happen to have tons of memory (16 gig for example).

As the matter of fact, as work, I have a 16gig ramdisk (out of 64 gig) for scratch files used by some FEA solvers. (linux 2.6.5-7.308-smp SuSE)

Some programs use their own scratch files regardless of how much memory you have (Nastran/Abaqus/Optistruct), ramdisk is extremely useful for those situations.

When I had XP Pro 32bit I installed 8GB ram (it was dirt cheap at the time) and superspeed ramdisk that enabled me to make a ramdisk using the ram above the 3.25GB limit that XP couldn't access.

(superspeed refers to this feature as their "extended memory access" and it does work as advertised)

So XP had 3.25GB to play with and I got a nice zippy 5.75GB ramdisk to play with.

Then I set XP's pagefile to use the ramdisk.