Win32 and Maximum RAm

Open forum for end-user questions about Wine. Before asking questions, check out the Wiki as a first step.
Forum Rules
Locked
TripleD
Newbie
Newbie
Posts: 2
Joined: Tue Dec 10, 2013 7:24 am

Win32 and Maximum RAm

Post by TripleD »

Sorry if this is a silly question, but I honestly can't find the answer.

If I create a "win32 prefix, is it subject to the normal RAM restrictions of a 32-bit system? that is, can it use more than 4GB of RAM while running an application?
oiaohm
Level 8
Level 8
Posts: 1020
Joined: Fri Feb 29, 2008 2:54 am

Re: Win32 and Maximum RAm

Post by oiaohm »

http://www.winehq.org/site/docs/winedev-guide/x2853

The answer is scarily yes. TripleD wine can use more than 4G of memory running win32 application. But the win32 application will not be able to see it directly.

Most because Linux is PAE compatible. So .dll.so for example only part might be placed in the normal 4G memory space Windows applications see rest out in another area. Same with native Linux .so files wine calls.

There are other cases as well. Like win32 applications using memory mapped files. These might remain in Linux memory even after they are no longer directly visable in the 4G normal windows address space.

So the 4G limit is not exaclty a hard limit on how many memory a win32 application can be using. It a hard number on how much a win32 application can do without doing special handling.
TripleD
Newbie
Newbie
Posts: 2
Joined: Tue Dec 10, 2013 7:24 am

Re: Win32 and Maximum RAm

Post by TripleD »

Interesting. So each program gets their own 4GB of virtual memory, and this memory is not necessarily the same space that other programs will see?

(I apologize for my terminology; it been a long time since I did low-level programming).

To give an idealized example: if I run two 32-bit applications on a computer with 8GB of RAM, PAE can map each program into it's own 4GB virtual memory space, which is then mapped into the physical memory. The extra memory, from the program's point of view, is useless, since it's still limited to 4GB. But from my point of view wine is sill taking advantage of the extra memory, thus ensuring that things run faster. Is that about right?

Thank you for your help.
oiaohm
Level 8
Level 8
Posts: 1020
Joined: Fri Feb 29, 2008 2:54 am

Re: Win32 and Maximum RAm

Post by oiaohm »

TripleD correct and incorrect.

If the applications are installed in the same wineprefix so much of the memory space has to be shared with each other because this is what Win32 applications expect. Win32 applications are mostly not made PAE aware so when passing handles with each other they are expecting raw addresses. So 8G could not be fully mapped. Now if you place both win32 applications into individual wineprefixes this would be 4G each.

Even that the full 8G of memory cannot be accessed by a 32 bit application directly. Does not make the extra space worthless as long as the OS can manage it(windows 32 bit again lacking PAE support in drivers so causing the means to use extra memory to be disabled). Like disc cache any file the application is not currently using does not need to be mapped into the applications address space but due to the extra space still can be in ram.

So the extra space is not useless to the application its just not directly usable. The indirect like fast access to files and other thing that would not been possible without the extra space add up.

Yes Linux 32 bit kernel in PAE mode has 4/0/0/4 virtual memory split. So kernel space has 4 G private. Each application is giving a 4G private. Only stuff visible between either applications to each other or kernel to applications is stuff directly shared to each. 64 bit Linux treats normal linux 32 bit applications like they are in PAE mode. 4G memory per application and independent pool for what ever the kernel is upto.

wineserver sets up the sharing between wine applications.

So 1 32 bit application + kernel in PAE mode or 64 bit kernel can consume quite a bit more than 4G. Not the full 8 G due to some bits being share.

Yes it very simple to forget the background actors. Think about attempting todo a stage show and the lead actor causes all the support to quit. Yes this is a important thing to remember. 1 very hungry application can end up with the Linux kernel deciding to kill it. Having only 4G of ram at times could be a very big mistake with 32 bit PAE Linux.
Locked