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 456231
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: enough bits?
by Thom_Holwerda on Thu 6th Jan 2011 19:34 UTC in reply to "RE[4]: enough bits?"
Thom_Holwerda
Member since:
2005-06-29

A Windows client SKU won't address more than 4Gb of physical memory. This means that applications can't use those physical pages either.


This is simply wrong.

"Address Windowing Extensions (AWE) is a set of extensions that allows an application to quickly manipulate physical memory greater than 4GB. Certain data-intensive applications, such as database management systems and scientific and engineering software, need access to very large caches of data. In the case of very large data sets, restricting the cache to fit within an application's 2GB of user address space is a severe restriction. In these situations, the cache is too small to properly support the application.

AWE solves this problem by allowing applications to directly address huge amounts of memory while continuing to use 32-bit pointers. AWE allows applications to have data caches larger than 4GB (where sufficient physical memory is present). AWE uses physical nonpaged memory and window views of various portions of this physical memory within a 32-bit virtual address space."


http://msdn.microsoft.com/en-us/library/aa366527(v=vs.85).aspx

Reply Parent Score: 1

RE[6]: enough bits?
by Neolander on Thu 6th Jan 2011 20:02 in reply to "RE[5]: enough bits?"
Neolander Member since:
2010-03-08

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.

Edited 2011-01-06 20:04 UTC

Reply Parent Score: 1

RE[7]: enough bits?
by oiaohm on Thu 6th Jan 2011 21:59 in reply to "RE[6]: enough bits?"
oiaohm Member since:
2009-05-30

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[6]: enough bits?
by malxau on Thu 6th Jan 2011 22:18 in reply to "RE[5]: enough bits?"
malxau Member since:
2005-12-04

"A Windows client SKU won't address more than 4Gb of physical memory. This means that applications can't use those physical pages either.


This is simply wrong.
"
Have you looked at my Bio? I work on Windows full time. If you want me to go over memory management, I can bore you to tears, but it's very unlikely that you'll be able to dismiss me that easily.

Firstly, here's the page that describes limits on physical addressing:
http://msdn.microsoft.com/en-us/library/aa366778(v=VS.85).aspx#physical_memory_limits_windows_7

Second, this section might be helpful (the part that talks about how PAE, /3Gb, and AWE are related and not related):
http://msdn.microsoft.com/en-us/library/aa366796(v=VS.85).aspx



That's all well and good, but it's still subject to the physical memory limits described in the link I gave above. See the part where it says "The physical pages that can be allocated for an AWE region are limited by the number of physical pages present in the machine, since this memory is never paged..." What this link really shows is that a single process, which has 2Gb of VA, can use greater than 2Gb of physical pages on a 32-bit client system. It cannot use more than 4Gb of physical pages, since that's the absolute maximum the client system will ever use.

It also shows that MS' implementation of AWE requires physical pages and is therefore unsuitable to extend addressing. On client systems it's only useful to get from 2Gb to (some value less than) 4Gb.

Reply Parent Score: 1

RE[7]: enough bits?
by Thom_Holwerda on Thu 6th Jan 2011 22:37 in reply to "RE[6]: enough bits?"
Thom_Holwerda Member since:
2005-06-29

It also shows that MS' implementation of AWE requires physical pages and is therefore unsuitable to extend addressing. On client systems it's only useful to get from 2Gb to (some value less than) 4Gb.


I'm sorry, I think we were talking past one another - I thought you meant that client versions of 32bit Windows had zero options to go past the 2GB limit for applications. We actually meant the same thing, except I was unaware of the 4GB limit of AWE. Thanks for clarifying!

Reply Parent Score: 1