Dynamic Memory Coming to Hyper-V Part 3…

re: Dynamic Memory Coming to Hyper-V Part 3…

Tekfreak — Sat, 12 Feb 2011 11:58:35 GMT

Text is missing on both sides. Please check your code.

re: Dynamic Memory Coming to Hyper-V Part 3…

Tekfreak — Sat, 12 Feb 2011 11:56:53 GMT

It's unpossible to print these articles !!!

re: Dynamic Memory Coming to Hyper-V Part 3…

PR — Mon, 31 Jan 2011 14:07:43 GMT

This is true in server OS scenarios but specially on VDI scenarios. Why to have all VMs to load the same file over and over again when there is already memory allocated with that same file? Why does VM2 loads a file with a specific checksum when that file is already loaded in memory by VM1?

On a VDI scenario where most of the loaded files are just the same, I still don’t understand this waste of memory allocation.

re: Dynamic Memory Coming to Hyper-V Part 3…

Eduardo Menegalli Nazato — Wed, 26 May 2010 15:24:18 GMT

Hey Jeff, is there a way to check if my hardware supports Large Memory Page?

And thanks for all info, very good article(s)!

re: Dynamic Memory Coming to Hyper-V Part 3…

dougsk — Wed, 14 Apr 2010 01:36:25 GMT

I'll second, or hrm fourth the recommendation, thank you for taking the time to explain that, and it's awesome to have the info to get my head wrapped around what we aren't going to be using, but of ...

... course what I really what to know is what we are going to be using, and how I can get my grubby hands on a copy of the service pack. :D

re: Dynamic Memory Coming to Hyper-V Part 3…

NyaRuRu — Mon, 12 Apr 2010 13:24:15 GMT

> Large Memory (2MB) Pages support is widely available in processors from AMD and Intel today.

> AMD has included Large Memory Page Support in the last few generations of Opterons and Intel has added support in the new "Nehalem" processors.

Let me make sure I understand you correctly.

You mean that Intel has added Large Memory (2MB) Pages in "Nehalem" and all other older x86/x86-64 processors of Intel do not support Large Memory (2MB) Pages, right?

re: Dynamic Memory Coming to Hyper-V Part 3…

bowulf — Thu, 08 Apr 2010 14:43:43 GMT

While SuperFetch may be a technology to utilize existing wasted memory pages in a physical environment, is it recommended in a VDI environment? Sure one can argue optimized desktop experience, but at the expense overall system VM/host ratio? My users may want a full aero desktop as well, but limitations of GPU slots and a desire for ROI may preclude perfect performance for meeting SLA's. I could also allocate 8GB of RAM to all virtual desktop as well, but is the additional memory worth the additional cost in additional number of hosts or having to purchase 8GB RAM sticks vs. cost-effective 4GB ones.

re: Dynamic Memory Coming to Hyper-V Part 3…

Mr EBE — Thu, 08 Apr 2010 10:13:21 GMT

Hello,

I'm 100% biased to Hyper-V, love it so much... but to tell that superfetch is great !! Common.. Having the RAM full of crap isn't Optimizing anything ! Its why Win7 crap it with only half the physical RAM, compared to Vista 100% (which was so unstable in its first year(s), mostly thx to this same superfetch) .

SuperFetch is a Design Error in today's Age.. and promoting it with VDI in the same sentence is quite...

frankly, most disapointing..

Take any computer, use it partly for this, partly for that, and when you want it 100% dedicated to something (this is optimizing), you know it isn't because the RAM if full of crap, and that ressource is needed with HDD access just to manage that crap ...

I'm living with MS tech all day long, full Hyper-V labs with quite all system center products etc.. But no one could make me believe this propaganda about superfetch, Giga of RAM being wasted (not "used"..)..

So much things change and will change.. I would not be suprised one day to have a WIndows OS without Superfetch :) or Some VDI's "Service Pack/enhancement" which will turn it off :-)

Beside, good Blog, thanx for all the sharing, the works, and please bring us Memory Overcommit

Conrad

re: Dynamic Memory Coming to Hyper-V Part 3…

eranb — Thu, 08 Apr 2010 06:44:45 GMT

There are several caveats with large pages that weren't told in this otherwise excellent blog:

1.They are pinned in physical memory. The OS cannot swap them because of obvious performance reasons. This may not be a problem for some cases but for some workloads this can be very problematic (Especially when the application that allocated Giga-bytes of Large pages is now suspended for some reason or another and it doesn't do any useful work. AFAIK, FreeBSD is the only OS that has the brain to efficiently swap even large pages.

2.The application must be modified to take advantage of large pages. And I believe that 99.9% of the applications today, especially for desktops don't use this functionality. FreeBSD and Solaris ar the only OS I know which can dynamically give large pages to applications according to their usage pattern.

re: Dynamic Memory Coming to Hyper-V Part 3…

chikura — Thu, 08 Apr 2010 05:28:56 GMT

Great article Jeff Woolsey,,

full of knowledge regarding all the latest realtime memory techniques,,,

increasing the interest on hyper-v more n more,,,

request to continue,,,

Thanks,

Santhosh Chikurambotla