lama

[32Bit or x86] Use more memory above 3.25GB

24 posts in this topic

This patch was around here since April but I just got my eye on it NOW! :thumbup

http://zh-deepxw.blogspot.com/2009/04/readyfor4gb.html (Direct Download Link)

If I'm understanding this right, the requirements are PAE hardware + Vista/Win7 (XP not supported)

For XPx86 systems, there is this workaround so softwares get memory above 3.25GB:

Some special RamDisks use PAE to address range beyond the limit (SuperSpeed's RamDisk Plus and Romex's RamDisk does that for NT OSes (XP and Vista) R. Loew's RamDisk64 does that for lagacy OSes (Win98,98SE,ME).

Once you install the ramdisk, you can set your PageFile path to that drive (set up Min and Max input according to the size of your RamDisk size). If you further need the pagefile on HDD, you can do it otherwise, its good to never see that kind of file in HDD. After next restart, you can test out any of your memory hogging program and get surprised

you can also optimize your system by transferring "TEMP" folder, "Temporary Internet Files" or "Cache" folder of Opera/Mozilla to RamDisk and enjoy the super speed installations and web surfing!

This serves the main goal: give softwares more memory :)

Edited by lama
0

Share this post


Link to post
Share on other sites

[request] If this ever works out for someone, please post your replies here...

0

Share this post


Link to post
Share on other sites

Ewwwwwwwwwww

Thats a real nasty and error prone solution...

0

Share this post


Link to post
Share on other sites
Ewwwwwwwwwww

Thats a real nasty and error prone solution...

Agree (with XP) but what about Win7 and Vista??? Its a patch and gets the job done :)

For 64Bit users, its best you remain there and new users should be encouraged for X64 anyways :D

EDIT: I was checking out the CAT DOG fight in this forum.thread and thought since this place has some lagacy and new patch projects, it may give them some idea to automatically make WinSetup address more memory (VLite or 7Lite when it comes) can be cool if it becomes less ugly though

Edited by lama
0

Share this post


Link to post
Share on other sites
For XPx86 systems, there is this workaround so softwares get memory above 3.25GB:

Some special RamDisks use PAE to address range beyond the limit (SuperSpeed's RamDisk Plus and Romex's RamDisk does that for NT OSes (XP and Vista) R. Loew's RamDisk64 does that for lagacy OSes (Win98,98SE,ME)

For the NT-family OSes that can also be achieved using the free Gavotte's Rramdisk, that you did not mention.

And, believe me, it does rock! :yes:

Edited by dencorso
0

Share this post


Link to post
Share on other sites
this was already discussed here:

http://www.msfn.org/board/index.php?showtopic=133516

it is possible, but not licensed by MSFT for client operating systems.

While Geoff Chappell's page (that you linked to) is technically accurate on what he discusses, he still fails to mention that you cannot (at least on Windows via the Win32 API) run an executable code block with an address above the 32bit boundary, because the 32bit CPU's registers won't be able to store an address that maps that high. PAE still limits you to a 4GB window, no matter where you slice it, although you can place it higher (above the 4GB boundary, for instance), to load a 32bit app's 2 or 3GB of VA (and the 2 or 1GB kernel VA) into that range when it's loaded. It's overhead for the OS (although probably not much, especially with today's processing speed and multi-core setups), and one that Microsoft only plans to support (or, to be more accurate, planned, as Server 2008 R2 is x64 only, and Win7 will very likely be the last x86 client) on server-class OSes. The RAMDisk drivers that get discussed, while good and useful, still suffer some drawbacks being PSE-36, namely things like all I/O doing double-buffering, or not being able to "slide" the 4GB mapped window like you can with PAE and AWE.

Also, with PAE, you've got some issues with overhead in the memory manager itself when you do interprocess communication, TLB reloads on context switching - and a bit more for this on multi-CPU systems, as the TLB buffers have to be synched to make sure they're all accurate in their virtual to physical TLB mappings (although Windows APIs do allow batching of this by an application to try and reduce the perf hit this will cause), you're storing more information in the session view space in kernel for PTE space, even though the kernel is still the same size with or without PTE, so there can be kernel pool and session space cramping on large memory systems in 32bit, and there are more that are documented on technet and MSDN if you want to read up.

Or, you could use an x64 OS and not have any of the overhead or restrictions of the Windows platform with regards to PAE and run everything natively (or in WOW64 isolation for a 32bit app, of course - with the side benefit that any 32bit app compiled LARGEADDRESSAWARE actually can use 4GB of VA instead of 3GB because there's no kernel space in the 32bit VA in WOW64). This is obviously easier for developers to handle, and there are other benefits above and beyond that x64 gives but that's outside the scope of this discussion.

Ultimately, does it matter? I dunno, I don't think most folks use more than 4GB anyway, and those of us that do are using x64 for reasons other than native support for more than 4GB memory. I still see it as the bridge Intel initially designed PAE (and PSE) for to allow for use of >4GB of RAM on x86 systems before they had their 64bit platform (Itanium) ready.

0

Share this post


Link to post
Share on other sites

I know, I only wanted to point out that it is possible to use more RAM, but it doesn't solve the issues with the x86 architecture.

But I still don't understand why you banned Geoff Chappell here on the board.

@lama

NeoWin is a spamming board with stupid children without technical background.

0

Share this post


Link to post
Share on other sites
he still fails to mention that you cannot (at least on Windows via the Win32 API) run an executable code block with an address above the 32bit boundary, because the 32bit CPU's registers won't be able to store an address that maps that high.

Since software reference only virtual memory that will never be an issue. A VA can point anywhere in physical memory - also above 4G even if the registers are only 32bit wide.

http://www.microsoft.com/whdc/system/platf...PAE/pae_os.mspx

1. Server Consolidation

A PAE-enabled operating system should be capable of utilizing all physical memory provided by the system to load multiple applications; for example, App#1, App#2, App #N, each consisting of 4 GB (maximum) of virtual address. In a non-PAE enabled system, the result can be a great deal of paging, since maximum physical memory in the system is limited to 4 GB.

With the additional physical memory supported under PAE mode, an operating system can keep more of these applications in memory without paging. This is valuable in supporting server consolidation configurations, where support of multiple applications in a single server is typically required. Note that no application changes are required to support this capability.

0

Share this post


Link to post
Share on other sites
Since software reference only virtual memory that will never be an issue. A VA can point anywhere in physical memory - also above 4G even if the registers are only 32bit wide.
Correct, Windows does the translation. However, there's still a perf hit for the translation and the TLB shoot down. The app just isn't aware of it.
0

Share this post


Link to post
Share on other sites

There is also a bit more translation overhead in 64bit mode.

"run an executable code block with an address above the 32bit boundary" is also not entirely true. That only applies when you are using AWE.

0

Share this post


Link to post
Share on other sites
There is also a bit more translation overhead in 64bit mode.
True, but everything in x64 is a fastcall, and there are double the CPU registers. It tends to negate the perf hit for TLB translation in the end, especially for native Windows binaries. And again, there's the added benefit of 4GB of VA available in WOW64 for 32bit apps compiled aware, as well, although I don't know many desktop apps other than graphics programs that do this.
0

Share this post


Link to post
Share on other sites
For XPx86 systems, there is this workaround so softwares get memory above 3.25GB:

Some special RamDisks use PAE to address range beyond the limit (SuperSpeed's RamDisk Plus and Romex's RamDisk does that for NT OSes (XP and Vista) R. Loew's RamDisk64 does that for lagacy OSes (Win98,98SE,ME)

For the NT-family OSes that can also be achieved using the free Gavotte's Rramdisk, that you did not mention.

And, believe me, it does rock! :yes:

hmmm? the link you gave me shows some problem of FAT on Gavotte's RamDisk BUT, Thanks! for the information ofcourse :) Now I have 3 RamDisks that addresses space above 3.25GB RAM

1. RamDisk Plus

2. Romex's RamDisk

3. Gavotte's RamDisk :)

I still prefer RamDiskPlus cauz its a full feature ramDisk (saves RamImage on exit etc) but, I will explore more ramdisks as i can

EDIT: Thanks for keeping your signature cool (it did help me install 9x so thanks again :) )

Edited by lama
0

Share this post


Link to post
Share on other sites
hmmm? the link you gave me shows some problem of FAT on Gavotte's RamDisk BUT, Thanks! for the information ofcourse :) Now I have 3 RamDisks that addresses space above 3.25GB RAM
No, I did not. I gave you a link to the right thread, not to a specific post. My ideia was that you'd read the whole thread (it's not very long), to know more about Gavotte's Rramdisk. If you look for it there is a post there, by myself, with the latest version of Rramdisk attached. Cheers!
0

Share this post


Link to post
Share on other sites

downloaded long time back (while i saw first few lines and replied) :D

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.