On 04/12/2010 02:22 PM, Arjan van de Ven wrote:
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.
I respectfully disagree with your analysis.
While it is true that the number of "level 1" tlb entries has not kept
up with ram or application size, the CPU designers have made it so that
there effectively is a "level 2" (or technically, level 3) in the cache.
A tlb miss from cache is so cheap that in almost all cases (you can
cheat it by using only 1 byte per page, walking randomly through memory
and having a strict ordering between those 1 byte accesses) it is
hidden in the out of order engine.
Pointer chasing defeats OoO. The cpu is limited in the amount of
speculation it can do.
Since you will likely miss on the data access, you have two memory
accesses to hide (3 for virt).
So in practice, for many apps, as long as the CPU cache scales with
application size the TLB more or less scales too.
A 16MB cache maps 8GB of memory (4GB with virtualization), leaving
nothing for data.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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>