On Mon, 5 Apr 2010, Pekka Enberg wrote: > > AFAIK, most modern GCs split memory in young and old generation > "zones" and _copy_ surviving objects from the former to the latter if > their lifetime exceeds some threshold. The JVM keeps scanning the > smaller young generation very aggressively which causes TLB pressure > and scans the larger old generation less often. .. my only input to this is: numbers talk, bullsh*t walks. I'm not interested in micro-benchmarks, either. I can show infinite TLB walk improvement in a microbenchmark. In order for me to be interested in any complex hugetlb crap, I want real numbers from real applications. Not "it takes this many cycles to walk a page table", or "it could matter under these circumstances". I also want those real numbers _not_ directly after a clean reboot, but after running other real loads on the machine that have actually used up all the memory and filled it with things like dentry data etc. The "right after boot" case is totally pointless, since a huge part of hugetlb entries is the ability to allocate those physically contiguous and well-aligned regions. Until then, it's just extra complexity for no actual gain. Oh, and while I'm at it, I want a pony too. Linus PS. I also think the current odd anonvma thing is _way_ more important. That was a feature that actually improved AIM throughput by 300%. Now, admittedly that's not a real load either, but at least it's not a total microbenchmark. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>