* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 5 Apr 2010, Linus Torvalds wrote: > > > > So I thought it was a more interesting load than it was. The > > virtualization "TLB miss is expensive" load I can't find it in myself to > > care about. "Get a better CPU" is my answer to that one, > > [ Btw, I do realize that "better CPU" in this case may be "future CPU". I > just think that this is where better TLB's and using ASID's etc is > likely to be a much bigger deal than adding VM complexity. Kind of the > same way I think HIGHMEM was ultimately a failure, and the 4G:4G split > was an atrocity that should have been killed ] Both highmem and 4g:4g were failures (albeit highly practical failures you have to admit) in the sense that their relevance faded over time. (because they extended the practical limits of the constantly fading, 32-bit world.) Both highmem and 4g:4g became less and less of an issue as hardware improved. OTOH are you saying the same thing about huge pages? On what basis? Do you think it would be possible for hardware to 'discover' physically-continuous 2M mappings and turn them into a huge TLB internally? [i'm not sure it's feasible even in future CPUs - and even if it is, the OS would still have to do the defrag and keep-them-2MB logic internally so there's not much difference.] The numbers seem rather clear: http://lwn.net/Articles/378641/ Yes, some of it is benchmarketing (most benchmarks are), but a significant portion of it isnt: HPC processing, DB workloads and Java workloads. Hugepages provide a 'final' performance boost in cases where there's no other software way left to speed up a given workload. The goal of Andrea's and Mel's patch-set, to make this 'final performance boost' more practical seems like a valid technical goal. We can still validly reject it all based on VM complexity (albeit the VM people wrote both the defrag part and the transparent usage part so all the patches are all real), but how can we legitimately reject the performance advantage? I think the hugetlb situation is more similar to the block IO transition to larger sector sizes in block IO or to the networking IO transition from host-side-everything to checksum-offload and then to TSO - than it is similar to highmem or 4g:4g. In fact the whole maintenance thought process seems somewhat similar to the TSO situation: the networking folks first rejected TSO based on complexity arguments, but then was embraced after some time. 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>