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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, 6 Apr 2010, Andrea Arcangeli wrote:
>
> Some performance result:

Quite frankly, these "performance results" seem to be basically dishonest.

Judging by your numbers, the big win is apparently pre-populating the page 
tables, the "tlb miss" you quote seem to be almost in the noise. IOW, we 
have 

	memset page fault 1566023

vs

	memset page fault 2182476

looking like a major performance advantage, but then the actual usage is 
much less noticeable.

IOW, how much of the performance advantage would we get from a _much_ 
simpler patch to just much more aggressively pre-populate the page tables 
(especially for just anonymous pages, I assume) or even just fault pages 
in several at a time when you have lots of memory?

In particular, when you quote 6% improvement for a kernel compile, your 
own numbers make seriously wonder how many percentage points you'd get 
from just faulting in 8 pages at a time when you have lots of memory free, 
and use a single 3-order allocation to get those eight pages?

Would that already shrink the difference between those "memset page 
faults" by a factor of eight?

See what I'm saying?  

		Linus

--
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>

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]