ESX keeps track of identical pages that could be shared once large pages are broken up so the overhead to break up the pages and begin sharing is likely minimal. These days with 6 and 8 core CPUs there is usually ample CPU resources available.

Since this blog post came out I’ve written another one that helps clarify how TPS behaves when using Nehalem processors. This post generated a lot of questions on TPS so I felt it was important to write another specifically on that topic.

http://blogs.kraftkennedy.com/index.php/2010/05/27/vmware-kb-clarifies-page-sharing-on-nehalem-processors/

Thanks for reading!

Matt
@mattliebowitz

I don’t think TPS is becoming useless. TPS still works correctly when you overcommitt memory, which is when you really need it to work in the first place. And as this blog post showed I wasn’t able to see any measurable difference with the ASLR feature of modern operating systems.

I’m confident VMware will continue to improve TPS and it will remain a viable and important feature.

Matt
@mattliebowitz

VMkernel swap shouldn’t be affected when using large pages. That said, swap should only kick in when memory is already scarce, so at that point the large pages would already be broken up into smaller pages and would be shared. The same is true for ballooning, though there are cases where ballooning could occur even without memory being scarce (such as when using memory limits).

I hope people aren’t getting the impression that large pages are a bad thing. Some tests have shown that workloads may perform better even when the guest OS doesn’t support large pages natively. ESX will break up the large pages only when memory has been overcommitted so there isn’t much of a need to proactively disable the use of large pages.

Hope this helps you and others who are wondering about this.

Matt
@mattliebowitz

>Transparent Page Sharing isn’t able to share large
>pages

What about swapping which is one of the three (so far) solution to free up memory when overcommiting?

Does swapping happen in 2MB blocks as well or does vSphere split it off in 4KB chunks or simply vSphere doesn’t swapp at all?

Thx,
Didier

Many thanks for this – the CPU is an Athlon II X4 (whitebox system at home) so you’re probably right. I’m not actually running out of memory so I’ll follow you’re advice and leave things as they are.

Thanks again,

Ian.

I suspect that you’re not actually seeing a problem with ASLR. I assume you’re using modern processors like an Intel Nehalem? If that is the case, what you’re seeing is most likely expected and normal.

Intel Nehalem and AMD Barcelona/Shanghai (among others) use large memory pages (2MB) as opposed to small pages (4K). Transparent Page Sharing isn’t able to share large pages, so memory sharing essentially doesn’t occur. It sounds like this is a problem but it is actually expected behavior and isn’t broken.

When you reach the point where you’ve overcommited memory (assign more RAM to VMs than is physically available), ESX will break up those large memory pages into small pages and begin to share them. At that point memory sharing will occur normally. You can force this behavior all the time instead by changing the advanced setting Mem.AllocGuestLargePage to 0. You can then reboot your guest and memory sharing will occur almost immediately.

Assuming this is your issue (and I suspect it is if the server is relatively new), I wouldn’t rush to enable this setting. The behavior you’re seeing is normal and isn’t broken, and memory sharing will kick in when you overcommit and actually need it.

Hope this helps.