OSRLogo
OSRLogoOSRLogoOSRLogo x Seminar Ad
OSRLogo
x

Everything Windows Driver Development

x
x
x
GoToHomePage xLoginx
 
 

    Sat, 21 Oct 2017     115112 members

   Login
   Join


 
 
Contents
  Online Dump Analyzer
OSR Dev Blog
The NT Insider
Downloads
ListServer / Forum
Driver Jobs
  Express Links
  · The NT Insider Digital Edition - May-June 2016 Now Available!
  · Windows 8.1 Update: VS Express Now Supported
  · HCK Client install on Windows N versions
  · There's a WDFSTRING?
  · When CAN You Call WdfIoQueueP...ously

Upsizing - Managing Address Space Increases for IA-64

One of the major changes in Windows XP® (and .NET) is the ability of the operating system to support the IA64 architecture with its sporty 64-bit registers and vastly larger virtual address space. Of course, many things had to change within Windows to accommodate this new, more roomy address space. Not the least of these was the virtual memory system, which had to grow to track this much larger space.

Some of the necessary changes have snuck in as Windows has gained the ability to support large memory machines (up to 32GB in Windows 2000® and 64GB in Windows XP on the IA32 architecture machines). For example, the size of the page addresses being used has increased, because a “standard” page table entry (PTE) on IA32 only uses 20 bits of addressing to describe the physical page location. Since 220 pages describe 4GB of physical memory (each of those 220 pages describes 212 bytes, and 220 * 212 = 232 bytes) it is clear that this is not enough addressing to describe machines with more physical memory. Of course, the solution was to increase the size of the PTE – use 64 bits instead of 32 bits. Then those extra bits can be used to describe additional physical memory.  Intel chose to use 4 of those extra bits, with the remaining 28 “extra” bits “reserved for future use” – no big surprise there!  So, Windows gained the ability to support large page table entries.

One down-side to this approach is that it means we can only store half as many PTEs in one page of memory. Thus, instead of getting 1024 entries in a page table, we now get 512 entries in the page table. The same applies to the page directory (since it also needs to expand to fit in more physical memory addressing bits). Thus, one page directory describes 512 (29) page tables. Each page table describes 512 (29) pages. One page directory thus describes 1GB of virtual address space (29 * 29 * 212 = 230). So we need four pages to describe the same 4GB virtual address space.

When we move up to the IA64 architecture platforms, we increase the size of a page to 8k. Thus, the PAGE_SIZE constant is double the 4k most developers expect from their work on the IA32 architecture machines. Each page table describes 1024 (210) entries, and each page directory describes 1024 (210) page tables. Thus, one page directory page describes 8GB of virtual address space (210 * 210 * 213 = 233 or 8GB). But this still isn’t enough! No worries. We introduce another layer of table management; to distinguish it from the page directory, we can call it the parent page entry (PPE, see Figure 1). Each parent page contains 1024 page table entries. With this, the virtual address space is now 8TB (243 bytes). By using one 8TB address space for the operating system, and a second 8TB address space for user applications, Windows XP and .NET now offer a full 16TB address space!

Figure 1 Parent Page Entry

With the newly opened address spaces of 64-bits beckoning, there is one category of application pushing to take advantage of it – databases. Database vendors wish to exploit both larger physical and virtual address spaces. So, while most applications can exist well within the existing 32-bit address spaces, the new frontier will be populated by vast database applications focused on using as much of this new memory as possible.

Related Articles
The Wide World Of The AMD64
No More Embedded Assembler or x87 FP
WHICH DDK Do I Use??

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

Post Your Comments.
Print this article.
Email this article.

Writing WDF Drivers I: Core Concepts
LAB

Nashua (Amherst), NH
15-19 May 2017

Writing WDF Drivers II: Advanced Implementation Techniques
LAB

Nashua (Amherst), NH
23-26 May 2017

Kernel Debugging and Crash Analysis
LAB

Dulles (Sterling), VA
26-30 Jun 2017

Windows Internals and Software Driver Development
LAB

Nashua (Amherst), NH
24-28 Jul 2017

 
 
 
 
x
LetUsHelp
 

Need to develop a Windows file system solution?

We've got a kit for that.

Need Windows internals or kernel driver expertise?

Bring us your most challenging project - we can help!

System hangs/crashes?

We've got a special diagnostic team that's standing by.

Visit the OSR Corporate Web site for more information about how OSR can help!

 
bottom nav links