• A
    x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range · e7b52ffd
    Alex Shi 提交于
    x86 has no flush_tlb_range support in instruction level. Currently the
    flush_tlb_range just implemented by flushing all page table. That is not
    the best solution for all scenarios. In fact, if we just use 'invlpg' to
    flush few lines from TLB, we can get the performance gain from later
    remain TLB lines accessing.
    
    But the 'invlpg' instruction costs much of time. Its execution time can
    compete with cr3 rewriting, and even a bit more on SNB CPU.
    
    So, on a 512 4KB TLB entries CPU, the balance points is at:
    	(512 - X) * 100ns(assumed TLB refill cost) =
    		X(TLB flush entries) * 100ns(assumed invlpg cost)
    
    Here, X is 256, that is 1/2 of 512 entries.
    
    But with the mysterious CPU pre-fetcher and page miss handler Unit, the
    assumed TLB refill cost is far lower then 100ns in sequential access. And
    2 HT siblings in one core makes the memory access more faster if they are
    accessing the same memory. So, in the patch, I just do the change when
    the target entries is less than 1/16 of whole active tlb entries.
    Actually, I have no data support for the percentage '1/16', so any
    suggestions are welcomed.
    
    As to hugetlb, guess due to smaller page table, and smaller active TLB
    entries, I didn't see benefit via my benchmark, so no optimizing now.
    
    My micro benchmark show in ideal scenarios, the performance improves 70
    percent in reading. And in worst scenario, the reading/writing
    performance is similar with unpatched 3.4-rc4 kernel.
    
    Here is the reading data on my 2P * 4cores *HT NHM EP machine, with THP
    'always':
    
    multi thread testing, '-t' paramter is thread number:
    	       	        with patch   unpatched 3.4-rc4
    ./mprotect -t 1           14ns		24ns
    ./mprotect -t 2           13ns		22ns
    ./mprotect -t 4           12ns		19ns
    ./mprotect -t 8           14ns		16ns
    ./mprotect -t 16          28ns		26ns
    ./mprotect -t 32          54ns		51ns
    ./mprotect -t 128         200ns		199ns
    
    Single process with sequencial flushing and memory accessing:
    
    		       	with patch   unpatched 3.4-rc4
    ./mprotect		    7ns			11ns
    ./mprotect -p 4096  -l 8 -n 10240
    			    21ns		21ns
    
    [ hpa: http://lkml.kernel.org/r/1B4B44D9196EFF41AE41FDA404FC0A100BFF94@SHSMSX101.ccr.corp.intel.com
      has additional performance numbers. ]
    Signed-off-by: NAlex Shi <alex.shi@intel.com>
    Link: http://lkml.kernel.org/r/1340845344-27557-3-git-send-email-alex.shi@intel.comSigned-off-by: NH. Peter Anvin <hpa@zytor.com>
    e7b52ffd
mmu.c 57.2 KB