Hi, Max Herrmann here again, from the Windows Server RDS team at Microsoft. Last month, I blogged about Microsoft RemoteFX – a key RDS platform capability that we will introduce with Windows Server 2008 R2 SP1 and which is designed to provide a media-rich, local-like user experience for virtual and session-based desktops and applications. The announcement of Microsoft RemoteFX created a lot of excitement in the market, especially among software and hardware partners who are already working on value-added solutions. So why is Microsoft RemoteFX important? Because its support for full-fidelity video as well as rich media and 3D graphics helps close the gap between the user experience of a local user sitting at their physical desktop and that of a remote user connected to a virtual desktop.
Today, I want to introduce another aspect of Microsoft RemoteFX and how it can further help close the user experience gap between physical and virtual desktops: Customers looking to deploy a virtual desktop infrastructure (VDI) expect their users to be able to plug any peripheral device into their client device and have it "just work" within a virtual desktop as if it was a physical desktop.
The situation today is that the Remote Desktop Protocol (RDP) only provides certain kinds of high-level redirection (such as printer redirection, disk drive redirection, PnP device redirection, etc). However, due to the wide variety of device types and variances in the quality and availability of drivers, it is impossible to provide a consistent high-level device redirection solution for every device across every platform used with RDP. As a result, device-specific solutions for each type of device are necessary.
A much better solution is to redirect devices at the USB level (or to be more specific, the USB request block, or URB level). With that type of solution, which we have chosen for VDI desktops, no device drivers are needed on the client device, and we can provide a universal interface that works with any USB device on any of our supported platforms. This solution is able to successfully redirect most of the devices users wish to use, including audio in/out devices, storage devices, HID devices (tablets, keyboards, etc.), and printers and scanners.
As with the above described rich media enhancements, where host-side rendering with RemoteFX will be additive to existing client-side rendering in RDP, RemoteFX USB redirection will also add to existing device redirection capabilities in RDP, rather than replacing them.
Whether you are one of the many customers having already successfully deployed a centralized desktop architecture with Terminal Services in the past, or you are looking to make the move to VDI or session virtualization with Remote Desktop Services in Windows Server 2008 R2 SP1, the new RemoteFX capabilities will greatly enhance the user experience for your remote users.
As I was saying in one of my previous blogs, this is just the beginning of an exciting time for centralized desktop computing and the benefits of the user experience enhancements that Microsoft RemoteFX will be delivering. So please do check in on my blog every once in a while to find out what else is new and cool about Microsoft RemoteFX.
Max
Check out Anant's blog post over at Dynamic Datacenter Alliance blog. He writes about updates to System Center Operations Manager and SC Virtual Machine Manager. These updates were made this week at MS Management Summit. Here's an excerpt from Anant's blog:
System Center Virtual Machine Manager · Service lifecycle management, including creation, deployment and updates to cloud apps/services - Leverages app virtualization technology and service modeling to perform image-based service composition, deployment and updates. · Creation of private clouds - Enables “Infrastructure as a Service” for the enterprise datacenter and allows self-service scenarios; discovery and assignment of logical/virtualized network and storage pools to apps/services · Federation across clouds - Enables workload mobility between on-premises, service provider and public clouds (e.g. Windows Azure) in a secure manner · Policy-based dynamic resource optimization – Ensure optimal utilization of your datacenter resources (e.g. policy driven power management), deeper Operations Manager/PRO integration · Deeper Opalis Integration – Offers deeper integration with Opalis for enhanced orchestration and automation across multiple sub-systems System Center Operations Manager · Unified on-premises and cloud monitoring - Enables hybrid cloud deployment scenarios with “single pane of glass” monitoring · Outside-in/end user experience monitoring for geo distributed cloud services (based on synthetic transactions) · Service oriented network and storage monitoring (e.g. monitor and troubleshoot network and storage resource pools assigned to services) Also check out this video I recorded to get additional information on our Datacenter vision and SCOM/VMM vNext.
System Center Virtual Machine Manager
· Service lifecycle management, including creation, deployment and updates to cloud apps/services - Leverages app virtualization technology and service modeling to perform image-based service composition, deployment and updates.
· Creation of private clouds - Enables “Infrastructure as a Service” for the enterprise datacenter and allows self-service scenarios; discovery and assignment of logical/virtualized network and storage pools to apps/services
· Federation across clouds - Enables workload mobility between on-premises, service provider and public clouds (e.g. Windows Azure) in a secure manner
· Policy-based dynamic resource optimization – Ensure optimal utilization of your datacenter resources (e.g. policy driven power management), deeper Operations Manager/PRO integration
· Deeper Opalis Integration – Offers deeper integration with Opalis for enhanced orchestration and automation across multiple sub-systems
System Center Operations Manager
· Unified on-premises and cloud monitoring - Enables hybrid cloud deployment scenarios with “single pane of glass” monitoring
· Outside-in/end user experience monitoring for geo distributed cloud services (based on synthetic transactions)
· Service oriented network and storage monitoring (e.g. monitor and troubleshoot network and storage resource pools assigned to services)
Also check out this video I recorded to get additional information on our Datacenter vision and SCOM/VMM vNext.
Patrick
=====================================================================
Preamble: The point of this series, and the spirit in which it is written, is to take a holistic approach at the issues facing our customers, discuss the complexities with regard to memory management and explain why we're taking the approach we are with Hyper-V Dynamic Memory. This isn't meant to criticize anyone or technology, rather to have an open and transparent discussion about the problem space.
In my last blog, we discussed Page Sharing in depth. To say this was a popular blog post would be a gross understatement. We received a lot of great feedback and a number of questions. So, I thought we'd close the loop on these questions about Page Sharing before getting to Second Level Paging in the next blog.
Questions
Q: When you say that Hyper-V R2 supports Large Memory Pages does that mean Hyper-V uses 2 MB memory page allocations or does that it mean it provides Large Memory Pages to the guest or both?
A: Both.
===================================================
Q: So, to take advantage of Large Memory Pages do applications have to be rewritten to use this functionality?
A: No. While having the guest operating system and applications use Large Memory Pages can be a good thing, it's important to note that applications don't have to be large page aware to benefit from Hyper-V's usage of Large Pages to back guest RAM.
Q: You mentioned that SuperFetch can impact Page Sharing efficacy as it eliminates zero pages. Isn't that a Windows specific feature, do other operating systems employ similar techniques?
A: Yes, other operating systems use similar techniques. For example, Linux has a feature called "Preload." Preload is an "adaptive readahead daemon" that runs in the background of your system, and observes what programs you use most often, caching them in order to speed up application load time. By using Preload, it utilizes unused RAM, and improves overall system performance.
BTW: OSNews said this about SuperFetch:
SuperFetch is something all operating systems should have. I didn't buy 4GB of top-notch RAM just to have it sit there doing nothing during times of low memory requirements. SuperFetch makes my applications load faster, which is really important to me - I come from a BeOS world, and I like it when my applications load instantly. SuperFetch' design makes sure that it does not impact the system negatively, but only makes the system smoother. Because it runs at a low-priority, its cache doesn't take away memory from the applications you're running.
SuperFetch is something all operating systems should have. I didn't buy 4GB of top-notch RAM just to have it sit there doing nothing during times of low memory requirements. SuperFetch makes my applications load faster, which is really important to me - I come from a BeOS world, and I like it when my applications load instantly.
SuperFetch' design makes sure that it does not impact the system negatively, but only makes the system smoother. Because it runs at a low-priority, its cache doesn't take away memory from the applications you're running.
http://www.osnews.com/story/21471/SuperFetch_How_it_Works_Myths
Q: You didn't mention Address Space Layout Randomization (ASLR) and if it impacts Page Sharing, does it?
A: I didn't cover ASLR because the blog was pretty long already, but since you asked...
Yes, ASLR does impact the Page Sharing efficacy, but first a quick description of ASLR from a TechNet article written by Mark Russinovich:
The Windows Address Space Layout Randomization (ASLR) feature makes it more difficult for malware to know where APIs are located by loading system DLLs and executables at a different location every time the system boots. Early in the boot process, the Memory Manager picks a random DLL image-load bias from one of 256 64KB-aligned addresses in the 16MB region at the top of the user-mode address space. As DLLs that have the new dynamic-relocation flag in their image header load into a process, the Memory Manager packs them into memory starting at the image-load bias address and working its way down.
Mark continues with...
In addition, ASLR's relocation strategy has the secondary benefit that address spaces are more tightly packed than on previous versions of Windows, creating larger regions of free memory for contiguous memory allocations, reducing the number of page tables the Memory Manager allocates to keep track of address-space layout, and minimizing Translation Lookaside Buffer (TLB) misses.
Today, the impact of ASLR on Page Sharing is relatively low ~10% compared to Large Memory Pages and SuperFetch, but it is indeed another factor that impacts Page Sharing efficacy. Moreover, that's not to say that future improvements in ASLR won't impact Page Sharing efficacy further.
Q: You mention that Large Memory Page Support in included in the last few generations of Opterons and Intel has added support in the new "Nehalem" processors. Do you mean older Intel x86/x64 do not support Large Memory Pages?
A: 5/6/2010: CORRECTION: Actually, older x86/x64 processors do support Large Memory Pages going back many generations. However, 32-bit systems generally didn't support generous amounts of memory (most maxed out at 4 GB which is a small fraction of what 64-bit systems support) so support for Large Memory Pages wasn't as crucial as it is now with 64-bit servers being the norm.
In my next blog we'll discuss Second Level Paging...
Jeff Woolsey
Principal Group Program Manager
Windows Server, Virtualization
P.S. Here are the links to all of the posts in this blog series:
Next Tuesday (20th) and Wednesday (21st) be sure to visit the Microsoft News Center to view the Microsoft Management Summit executive keynotes live on the web. Don’t miss this opportunity to see Bob Muglia and Brad Anderson discuss the latest IT Management news, MS strategies for datacenter and desktop management, and virtualization and cloud solutions from Microsoft. And did I mention demos of new and upcoming products.
· Tuesday, April 20, 8:30 – 9:45 AM PST: Managing Systems from the Datacenter to the Cloud, Bob Muglia, president, Microsoft Server and Tools
· Wednesday, April 21, 8:30 – 9:45 AM PST: User Centric Client Management, Brad Anderson, corporate vice president, Management and Services Division
======================================================
Preamble: The point of this series, and the spirit in which it is written, is to take a holistic approach at the issues facing our customers, discuss the complexities with regard to memory management and explain why we’re taking the approach we are with Hyper-V Dynamic Memory. This isn’t meant to criticize anyone or technology, rather to have an open and transparent discussion about the problem space.
Memory Overcommit, an Overloaded Term…
When it comes to virtualization and memory, I regularly hear the term “memory overcommit” used as if it’s a single technology. The problem is that there are numerous techniques that can be employed to more efficiently use memory which has led to much confusion. Some customers think page sharing equals overcommit. Others think second level paging equals memory overcommit and so on.
So, to avoid any confusion, here’s the definition of overcommit according to the Merriam Webster dictionary online:
http://www.merriam-webster.com/dictionary/overcommit Main Entry: over·com·mit : to commit excessively: as a : to obligate (as oneself) beyond the ability for fulfillment b : to allocate (resources) in excess of the capacity for replenishment
http://www.merriam-webster.com/dictionary/overcommit
Main Entry: over·com·mit
: to commit excessively: as a : to obligate (as oneself) beyond the ability for fulfillment b : to allocate (resources) in excess of the capacity for replenishment
Memory overcommit simply means to allocate more memory resources than are physically present. In a physical (non-virtualized) environment, the use of paging to disk is an example of memory overcommit. Now that we’ve defined it, I’m done using this term to avoid the aforementioned confusion. From here on, I’m going to refer to specific memory techniques.
In a virtualized environment, there are a variety of different memory techniques that can be employed to more efficiently use memory such as page sharing, second level paging and dynamic memory balancing (e.g. ballooning is one technique, hot add/remove memory is another). Each one of these methods has pros and cons and varying levels of efficacy.
Today we’ll discuss Page Sharing in detail.
BTW, before we dive in, let me state at the onset that we have spent a lot of time looking at this technology and have concluded that it is not the best option for us to use with dynamic memory. Hopefully, this will explain why…
How Page Sharing Works
Page Sharing is a memory technique where the hypervisor inspects and hashes all memory in the system and stores it in a hash table. Over time, which can be hours, the hashes are compared and if identical hashes are found, a further bit by bit comparison is performed. If the pages are exactly the same, a single copy is stored and multiple VMs memory are mapped to this shared page. If any one of these virtual machines need to modify that shared page, copy on write semantics are used resulting in a new (and thus unshared) memory page.
Page Sharing is a well understood memory technique and there are a number of factors that contribute to its efficacy such as:
Page Sharing, TLBs, Large Memory Pages & More…
To discuss Large Memory Page Support and its implications on Page Sharing, let’s take a step back and level set. For that, I’m going to reference an excellent article written by Alan Zeichick from AMD in 2006. While the focus of this article discusses the implications of large memory pages and java virtual machines, it also applies to machine virtualization. I’m going to reference specific sections, but if you’d like to read the full article it is here:
http://developer.amd.com/documentation/articles/pages/2142006111.aspx
All x86 processors and modern 32-bit and 64-bit operating systems allocate physical and virtual memory in pages. The page table maps virtual address to physical address for each native application and "walking" it to look up address mappings takes time. To speed up that process, modern processors use the translation lookaside buffer (TLB), to cache the most recently accessed mappings between physical and virtual memory. Often, the physical memory assigned to an application or runtime isn't contiguous; that's because in a running operating system, the memory pages can become fragmented. But because the page table masks physical memory address from applications, apps think that they do have contiguous memory. (By analogy, think about how fragmented disk files are invisible to applications; the operating system's file system hides all of it.) When an application needs to read or write memory, the processor uses the page table to translate the virtual memory addresses used by the application to physical memory addresses. As mentioned above, to speed this process, the processor uses a cache system—the translation lookaside buffers. If the requested address is in the TLB cache, the processor can service the request quickly, without having to search the page table for the correct translation. If the requested address is not in the cache, the processor has to walk the page table to find the appropriate virtual-to-physical address translation before it can satisfy the request.
All x86 processors and modern 32-bit and 64-bit operating systems allocate physical and virtual memory in pages. The page table maps virtual address to physical address for each native application and "walking" it to look up address mappings takes time. To speed up that process, modern processors use the translation lookaside buffer (TLB), to cache the most recently accessed mappings between physical and virtual memory.
Often, the physical memory assigned to an application or runtime isn't contiguous; that's because in a running operating system, the memory pages can become fragmented. But because the page table masks physical memory address from applications, apps think that they do have contiguous memory. (By analogy, think about how fragmented disk files are invisible to applications; the operating system's file system hides all of it.)
When an application needs to read or write memory, the processor uses the page table to translate the virtual memory addresses used by the application to physical memory addresses. As mentioned above, to speed this process, the processor uses a cache system—the translation lookaside buffers. If the requested address is in the TLB cache, the processor can service the request quickly, without having to search the page table for the correct translation. If the requested address is not in the cache, the processor has to walk the page table to find the appropriate virtual-to-physical address translation before it can satisfy the request.
The TLB's cache is important, because there are a lot of pages! In a standard 32-bit Linux, Unix, or Windows server with 4GB RAM, there would be a million 4KB small pages in the page table. That's big enough—but what about a 64-bit system with, oh, 32GB RAM? That means that there are 8 million memory 4KB pages on this system.
Mr. Zeichick continues:
Why is it [Large Pages] better? Let's say that your application is trying to read 1MB (1024KB) of contiguous data that hasn't been accessed recently, and thus has aged out of the TLB cache. If memory pages are 4KB in size, that means you'll need to access 256 different memory pages. That means searching and missing the cache 256 times—and then having to walk the page table 256 times. Slow, slow, slow. By contrast, if your page size is 2MB (2048KB), then the entire block of memory will only require that you search the page table once or twice—once if the 1MB area you're looking for is contained wholly in one page, and twice if it splits across a page boundary. After that, the TLB cache has everything you need. Fast, fast, fast. It gets better. For small pages, the TLB mechanism contains 32 entries in the L1 cache, and 512 entries in the L2 cache. Since each entry maps 4KB, you can see that together these cover a little over 2MB of virtual memory. For large pages, the TLB contains eight entries. Since each entry maps 2MB, the TLBs can cover 16MB of virtual memory. If your application is accessing a lot of memory, that's much more efficient. Imagine the benefits if your app is trying to read, say, 2GB of data. Wouldn't you rather it process a thousand buffed-up 2MB pages instead of half a million wimpy 4KB pages?
Why is it [Large Pages] better? Let's say that your application is trying to read 1MB (1024KB) of contiguous data that hasn't been accessed recently, and thus has aged out of the TLB cache. If memory pages are 4KB in size, that means you'll need to access 256 different memory pages. That means searching and missing the cache 256 times—and then having to walk the page table 256 times. Slow, slow, slow.
By contrast, if your page size is 2MB (2048KB), then the entire block of memory will only require that you search the page table once or twice—once if the 1MB area you're looking for is contained wholly in one page, and twice if it splits across a page boundary. After that, the TLB cache has everything you need. Fast, fast, fast.
It gets better.
For small pages, the TLB mechanism contains 32 entries in the L1 cache, and 512 entries in the L2 cache. Since each entry maps 4KB, you can see that together these cover a little over 2MB of virtual memory.
For large pages, the TLB contains eight entries. Since each entry maps 2MB, the TLBs can cover 16MB of virtual memory. If your application is accessing a lot of memory, that's much more efficient. Imagine the benefits if your app is trying to read, say, 2GB of data. Wouldn't you rather it process a thousand buffed-up 2MB pages instead of half a million wimpy 4KB pages?
Kudos, Mr. Zeichick.
I expanded on Mr. Zeichick’s physical memory to page table entry example and created this table to further illustrate the situation with 4KB pages at varying physical memory sizes.
When you consider that servers have supported 32/64 GB of memory for years now and that many industry standard servers shipping today, like the HP DL 385 G6, support up to 192 GB of memory per server today you can quickly see that the time for larger memory page support is overdue. Take a look at the recently released Nehalem EX processor. The Nehalem EX supports up to 256 GB of memory per socket. You could theoretically have a 4 socket server with 1 TB of physical memory. Do you really want to access all this memory 4k at a time?
(Even with just 64 GB of physical memory in a server, think of this as filling up an Olympic size swimming pool with water one 8 ounce cup at a time and it just gets worse as you add and use more memory…)
Key Points:
There’s More: SLAT, NPT/RVI, EPT and Large Pages…
One point I want to add is how Large Pages and Second Level Address Translation (SLAT) hardware coexist. With nested paging, (AMD calls this Rapid Virtualization Indexing (RVI) and/or Nested Page Tables (NPT), while Intel calls this Extended Page Tables or EPT) a page table in the hardware takes care of the translation between the guest address of a VM and the physical address, reducing overhead. With SLAT hardware, performance is generally improved about 20% across the board, and can be much higher (independent third parties have reported 100%+ performance improvements) depending on how memory intensive the workload is. In short, SLAT hardware is goodness and if you’re buying a server today as a virtualization host you want to ensure you’re purchasing servers with this capability.
One important point that doesn’t appear to be well-known is that SLAT hardware technologies are designed and optimized with Large Memory Pages enabled. Essentially, the additional nesting of page tables makes TLB cache misses more expensive resulting in about a ~20% performance reduction if you’re using SLAT hardware with Large Memory Page Support disabled. Furthermore, that’s not including the 10-20% average performance improvement (could be more) expected by using Large Memory Pages in the first place. Potentially, we’re talking about a 40% performance delta running on SLAT hardware depending on whether Large Memory Pages are used or not.
You may want to read those last two paragraphs again.
In short, using Large Memory Pages is a no brainer. You definitely want to take advantage of Large Memory Pages:
HW Evolution, Large Memory Pages & the Implications on Page Sharing
Computing hardware is in a constant state of evolution. Take networking for example. Originally, the frame size for Ethernet was 1518 bytes largely due to the fact that early networks operated at much lower speeds and with higher error rates. As networking evolved and improved (faster and with lower error rates), the 1518 byte size was recognized as a bottleneck and jumbo frames were introduced. Jumbo frames are larger, up to 9014 bytes in length, and deliver 6x more packets per payload and reduce CPU utilization by reducing the number of interrupts.
Large Memory Pages is a similar situation where server hardware is evolving to improve the overall system scale and performance. As a byproduct of this evolution, it changes some base assumptions. Specifically, Large Memory Pages changes the fundamental assumption of small 4k memory pages to larger and more efficient 2MB memory pages. However, there are implications to changing such fundamental assumptions. While you can identify and share 4k pages relatively easily, the likelihood of sharing a 2MB page is very, very low (if not, zero). In fact, this is an area where Microsoft and VMware agree. VMware acknowledges this point and states as much.
From VMware:
The only problem is that when large pages is used, Page Sharing needs to find identical 2M chunks (as compared to 4K chunks when small pages is used) and the likelihood of finding this is less (unless guest writes all zeroes to 2M chunk) so ESX does not attempt collapses large pages and thats [sic] why memory savings due to TPS goes down when all the guest pages are mapped by large pages by the hypervisor. http://communities.vmware.com/message/1262016#1262016
The only problem is that when large pages is used, Page Sharing needs to find identical 2M chunks (as compared to 4K chunks when small pages is used) and the likelihood of finding this is less (unless guest writes all zeroes to 2M chunk) so ESX does not attempt collapses large pages and thats [sic] why memory savings due to TPS goes down when all the guest pages are mapped by large pages by the hypervisor.
http://communities.vmware.com/message/1262016#1262016
Bottom Line: Page Sharing works in a legacy 4k Memory Page world, but provides almost no benefit in a modern 2MB Memory Page world.
As stated previously, support for Large Memory Pages is a no brainer. In fact, when designing Hyper-V Dynamic Memory, we were sure to optimize in the case where Large Memory Pages are present because we expect it will soon be standard. We are so confident in Large Memory Page support that:
Memory page size is evolutionary. You can expect memory page size to grow beyond 2MB to even larger page sizes in the future. In fact, newer AMD64 processors can use 1GB pages in long mode and Intel is adding 1GB memory page support in their upcoming Westmere processors. (BTW, that’s not a typo, 1GB pages…)
In addition to Large Page Memory, another factor impacting the efficacy of Page Sharing is OS Memory Utilization and Zero Pages.
Page Sharing, OS Memory Utilization & Zero Pages
One aspect of page sharing most people may not know is that the greatest benefit of page sharing comes from sharing zeroed pages. Let’s assume for a moment that I have a Windows XP system with 2GB of memory. As you can see in the screenshot below from a freshly booted system running Windows XP with no apps, the OS is using ~375MB of memory while the remaining memory ~1.8GB is unused and unfortunately wasted.
In reality, you want the operating system to take full advantage of all the memory in the system and use it as an intelligent cache to improve system performance and responsiveness. If you’re going to buy a brand new system (I see an online ad today for a brand new quad core system with 8 GB of memory for $499) don’t you want the OS to use that memory? Of course you do. That’s why we created SuperFetch.
SuperFetch keeps track of which applications you use most and loads this information in RAM so that programs load faster than they would if the hard disk had to be accessed every time. Windows SuperFetch prioritizes the programs you're currently using over background tasks and adapts to the way you work by tracking the programs you use most often and pre-loading these into memory. With SuperFetch, background tasks still run when the computer is idle. However, when the background task is finished, SuperFetch repopulates system memory with the data you were working with before the background task ran. Now, when you return to your desk, your programs will continue to run as efficiently as they did before you left. It is even smart enough to know what day it is in the event you use different applications more often on certain days.
OK, so how is RAM usage affected? You may have noticed that Windows 7 tends to use a much greater percentage of system RAM than on Windows XP. It is not uncommon to view Task Manager on a Windows 7 system with several GB of RAM installed and less than 100MB of the RAM shows up as free. For instance, here is a screenshot of Task Manager from the machine I am working on now.
As you can see, this system has 8GB of physical memory and is using 3.29 GB. I'm running Windows 7 x64 Edition, Outlook, One Note, Word, Excel, PowerPoint, Windows Live Writer, Live Photo Gallery, several instances of IE with over a dozen tabs open and other day to day tools and you can see that it shows 0 MB of free physical memory. At first glance, this would seem to be something to worry about, but once you consider the impact of SuperFetch this condition becomes less of a concern. Notice that ~5827MB is being used for cache.
Excellent.
Windows 7 is fully utilizing the system memory resources and intelligently caching so that I have a responsive system (fetching less from disk) with great performance and making it more likely the hard drive can spin down to save power to provide longer battery life.
So, why am I explaining Zero Pages and SuperFetch?
Because page sharing obtains the greatest benefit by page sharing zero pages running older operating systems and is less efficacious on modern operating systems. Like Jumbo Frame and Large Memory Pages, SuperFetch is another example of evolutionary changes in computing.
In talking with customers who are investigating hosting virtual desktops, they told us that Windows 7 is their overwhelming choice. This was another important data point in determining how we chose to implement dynamic memory because making the assumption that an OS will have lots of zero pages around isn’t a good one today or for the future.
Final Points on Page Sharing
To sum up…
Large Memory (2MB) Pages support is widely available in processors from AMD and Intel today. AMD and Intel have included support for Large Memory Pages going back many generations of x86/x64 processors. However, 32-bit systems generally didn't support generous amounts of memory (most maxed out at 4 GB which is a small fraction of what 64-bit systems support) so support for Large Memory Pages wasn't as crucial as it is now with 64-bit servers being the norm.
I hope this blog demonstrates that we have spent a lot of time looking at this technology and after significant analysis concluded it is not the best option for us to employ with Hyper-V Dynamic Memory. Moreover, the case for supporting Large Memory Pages is a no brainer. We feel so strongly about supporting Large Memory Pages that when designing Hyper-V Dynamic Memory, we were sure to optimize in the case where Large Memory Pages are present because we expect it to be standard. The benefits are too great to pass up. The good news is that there are other ways to pool and allocate memory and Hyper-V Dynamic Memory is a good solution for desktop and server operating systems.
In my next blog, we’ll discuss second level paging.
Windows Server Hyper-V