Re: [PATCH 00 of 41] Transparent Hugepage Support #17

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-foundation.org> 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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>