* Avi Kivity <avi@xxxxxxxxxx> wrote: > On 04/11/2010 02:52 PM, Ingo Molnar wrote: > > > > Put in a different way: this slow, gradual phsyical process causes > > data-cache misses to become 'colder and colder': in essence a portion of > > the worst-case TLB miss cost gets added to the average data-cache miss > > cost on more and more workloads. (Even without any nested-pagetables or > > other virtualization considerations.) The CPU can do nothing about this - > > even if it stays in a golden balance with typical workloads. > > This is the essence and which is why we really need transparent hugetlb. > Both the tlb and the caches are way to small to handle the millions of pages > that are common now. > > > This is why i think we should think about hugetlb support today and this > > is why i think we should consider elevating hugetlbs to the next level of > > built-in Linux VM support. > > Agreed, with s/today/yesterday/. Well, yes - with the caveat that i think yesterday's hugetlb patches were notwhere close to being mergable. (and were nowhere close to addressing the problems to begin with) Andrea's patches are IMHO a game changer because they are the first thing that has the chance to improve a large category of workloads. We saw it that the 10-years-old hugetlbfs and libhugetlb experiments alone helped very little: a Linux-only opt-in performance feature that takes effort [and admin space configuration ...] on the app side will almost never be taken advantage of to make a visible difference to the end result - it simply doesnt scale as a development and deployment model. The most important thing the past 10 years of kernel development have taught us are that transparent, always-available, zero-app-effort kernel features are king. The rest barely exists. Ingo -- 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>