Linked by Thom Holwerda on Wed 5th Jan 2011 22:09 UTC
Windows And this is part two of the story: Microsoft has just confirmed the next version of Windows NT (referring to it as NT for clarity's sake) will be available for ARM - or more specifically, SoCs from NVIDIA, Qualcomm, and Texas Instruments. Also announced today at CES is Microsoft Office for ARM. Both Windows NT and Microsoft Office were shown running on ARM during a press conference for the fact at CES in Las Vegas.
Thread beginning with comment 456242
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: enough bits?
by oiaohm on Thu 6th Jan 2011 21:59 UTC in reply to "RE[6]: enough bits?"
Member since:

It's not this simple.

I don't know how Microsoft implemented this in practice, but the way I see it they only have a few choices :
-Having application developers swap data in and out of their application's address space all by themselves (cumbersome)
-Having applications not directly access their data, but only manipulate it through 64-bit pointers which are sent to the operating system for every single operation. They can do that e.g. by having the extra RAM being manipulated as a file (slow because of the kernel call overhead)

Really, PAE is only good for multiple large processes which each use less than 4GB. Having an individual process manipulate more than 4GB on a 32-bit system remains a highly cumbersome operation.

32 bit Applications on Linux don't know they are on PAE or not. So application developers don't need to know about it.

A simple trick. Virtual memory ie swap out. To 32 be application this is what can appeared to have happened to the memory. Infact the memory block as just been placed in PAE Memory block outside the 4g address space. It way faster to get memory back using PAE than using swap.

Yes simple PAE treat it as a Ram based swapfile all complexity solved since 32 bit applications have to put up with swapfiles in the first place.

PAE is a good performance boost on 32 bit system running large applications that with 4 Gb limit would be running swap like mad. Yes Harddrive massively slow.

Now drivers and anything running in kernel mode is a different case. Lot of Windows drivers are not PAE huge memory aware. Even so there are ways around this issue while still taking advantage of PAE. Yes again drivers have to be swapaware or they will cause trouble. Being PAE aware does avoid having to pull page back into main memory for driver to place its data. Still way better than if that page had been sent to disk and had to be pulled back.

Basically there is technically no valid reason to limit particular version of windows to 4gb of memory. Heck Windows Starter has a fake limit of 1gb of memory. The 4gb limit was nice and simple to blame on 32 bit limit.

Cannot MS write a simple ram based swap system using PAE?

Yes it gets trickier with PAE 32 bit when you have duel core. Since to get most advantage out of PAE you have to use it for NUMA. Is this something applications need to worry about. Answer no.

Everything to support PAE is kernel based. Just has to be done right.

Reply Parent Score: 1

RE[8]: enough bits?
by Neolander on Thu 6th Jan 2011 22:13 in reply to "RE[7]: enough bits?"
Neolander Member since:

I can't understand how that swapping you describe could possibly work.

As we both know, ordinary swapping occurs when you run out of physical memory, but you still have some spare linear addresses around. In that case, all the kernel has to do is to allocate a new range of linear addresses and return a pointer to the beginning of it as usual, but mark the corresponding pages as absent.

Later on, when the process tries to access one of these newly allocated linear addresses, a page fault occurs. The kernel is summoned, and it swaps some things in and out so that the requested data ends up being in RAM. Then it makes the non-present linear addresses point there, marks them as present, and the process starts running again as if nothing happened.

But what we're talking about is totally different. It's when we are running out of linear addresses, but still have some spare physical addresses. The virtual address space of the application is now full, even though the RAM is not.

In that case, malloc() and such simply can't work anymore. Because there is no new pointer they could possibly use and return. All possible pointers of 32-bit addressing are already in use somewhere in the process. There is no such thing as a spare linear address range which we could mark as non-present as we do in swapping.

Edited 2011-01-06 22:25 UTC

Reply Parent Score: 1