Revision as of 00:45, 15 October 2016 editSineBot (talk | contribs)Bots2,555,318 editsm Signing comment by Paex86 - "→"offset within page" does not come from the page-table entry: "← Previous edit | Revision as of 03:37, 15 October 2016 edit undoClueBot III (talk | contribs)Bots1,373,531 editsm Archiving 1 discussion to Talk:Physical Address Extension/Archives/2016/July. (BOT)Next edit → | ||
Line 15: | Line 15: | ||
|archivenow=<nowiki>{{ArchiveNow}},{{ArchiveThisNowPlease}},{{resolved|,{{Resolved|,{{done}},{{Done}},{{Done|}}</nowiki> | |archivenow=<nowiki>{{ArchiveNow}},{{ArchiveThisNowPlease}},{{resolved|,{{Resolved|,{{done}},{{Done}},{{Done|}}</nowiki> | ||
}} | }} | ||
== according to Geoff Chappel", Microsoft may limit 32-bit versions of Windows to 4GB as a matter of its licensing policy == | |||
This was finally confirmed by Rusonnovich with Internals 6. | |||
6th Edition came out in 2 parts; Book 1 & Book 2. Book 2 contains a fair bit of undocumented info not found elsewhere. | |||
Page 320/321 lists physical memory support for all Windows versions, as on MSDN, AND the limiting factors, which are: | |||
"Licensing on 64-bit; '''licensing, hardware support'', and driver compatibility '''on 32-bit''" | |||
p320 | |||
''problematic client driver ecosystem led to the decision for client editions to | |||
ignore physical memory that resides above 4 GB''', even though they can theoretically address it'' | |||
p321 | |||
Exactly as Geoff Chappell said...:) | |||
It wasn't much of a secret tbh because AMD64 platforms running XP already made great use of 4-8GB RAM: No pagefile required. :) | |||
Great for servers. | |||
Coming from Managed Services (Deployment), published material often proves more reliable than say MSDN libraries which can be rather ambiguous....... | |||
No idea how to include a link to source which is '''Microsoft Windows Internals (6th Edition), Part 2, pages 320 & 321,''' | |||
As a wiki newbie so I apologise in advance for breaking any rules. :) | |||
I saw some discussion also over absolute maximum RAM limits allowed by Microsoft...? | |||
The official maximum is 2TB, the limit doesn’t come from any implementation or hardware limitation, but because Microsoft will support only configurations it can test. The largest tested and supported memory configuration is currently 2TB. <!-- Template:Unsigned IP --><small class="autosigned">— Preceding ] comment added by ] (]) 18:53, 14 July 2016 (UTC)</small> <!--Autosigned by SineBot--> | |||
== "offset within page" does not come from the page-table entry == | == "offset within page" does not come from the page-table entry == |
Revision as of 03:37, 15 October 2016
This is the talk page for discussing improvements to the Physical Address Extension article. This is not a forum for general discussion of the article's subject. |
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article has not yet been rated on Misplaced Pages's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details.
{{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details.
|
Archives (Index) |
This page is archived by ClueBot III. |
"offset within page" does not come from the page-table entry
The phrase should surely be . — Preceding unsigned comment added by 83.218.4.174 (talk) 23:56, 12 October 2016 (UTC)
- You are of course correct - and nice catch, that's been on the page for a long time. You can of course make the change yourself if you want. Be WP:BOLD ! Jeh (talk) 03:08, 13 October 2016 (UTC)
- Great, I agree with you, not "from the linear virtual address...", but from the linear address. We could keep differentiating simplify linear addressing from virtual address, because the latter could also used to represents the former. — Preceding unsigned comment added by Paex86 (talk • contribs) 00:44, 15 October 2016 (UTC)
" they defined an enhanced version of PAE", How Can We Interpret this "Enhanced Version"?
Misplaced Pages.org always have a lot of invented words by a lot of so called famous professionals. Maybe those are the prominent features of wiki articles. We read, we learn and we appreciate all the motivations around them all.
Paging scheme, which AMD64 architecture adopted, is similar with the scheme using in the PAE, and also further extended into an additional paging level. So this "enhanced", we could see at this point. But is it an enhanced version of PAE? In order to answer this question, we have to take a deeper look at what PAE really is!
PAE is short for Physical Address(ing) Extension, from 16-bit to 32-bit, we call it an expansion. But from 32-bit towards 36-bit and even more, we could only call it an extension. For this extension, we could ensure that the extended part is not easy to touch, in other words, the map between 32-bit and 36-bit is not easily and directly one-to-one mapped, but further taking advantage of paging capability. So PAE, is not only an extension of Physical Address, but also an extension of paging found in Intel 80386.
Now we have to take a look at paging in AMD64, this is a partial-to-partial paging schema, 48-bit linear address towards to up to 48-bit physical address. Obviously, there is no extension, so paging in AMD64 is not an PAE enabled, but just like another version of paging found in 80386, designed for 64-bit computing. Without changing the current scheme, it is hard to page 48-bit or more linear address to physical address larger than what 48-bit address could represent. This ensures the presumption that there is no extension at all once again.
So "They defined an enhanced version of PAE" is logically wrong. We could make a little bit correction towards it, i.e. they defined an enhanced version of paging scheme found in PAE. That would be much better. — Preceding unsigned comment added by Paex86 (talk • contribs) 00:34, 15 October 2016 (UTC)
Categories: