linux_dsm_epyc7002/arch/x86/include/asm/tlb.h

#ifndef _ASM_X86_TLB_H
#define _ASM_X86_TLB_H

#define tlb_start_vma(tlb, vma) do { } while (0)
#define tlb_end_vma(tlb, vma) do { } while (0)
#define __tlb_remove_tlb_entry(tlb, ptep, address) do { } while (0)

#define tlb_flush(tlb)							\
{									\
	if (!tlb->fullmm && !tlb->need_flush_all) 			\
		flush_tlb_mm_range(tlb->mm, tlb->start, tlb->end, 0UL);	\
	else								\
		flush_tlb_mm_range(tlb->mm, 0UL, TLB_FLUSH_ALL, 0UL);	\
}

#include <asm-generic/tlb.h>

#endif /* _ASM_X86_TLB_H */
x86: Fix ASM_X86__ header guards Change header guards named "ASM_X86__" to "_ASM_X86_" since: a. the double underscore is ugly and pointless. b. no leading underscore violates namespace constraints. Signed-off-by: H. Peter Anvin <hpa@zytor.com> 2008-10-23 12:26:29 +07:00			`#ifndef _ASM_X86_TLB_H`
			`#define _ASM_X86_TLB_H`
x86: unify include/asm/tlb_32/64.h Same file, except for whitespace, comment formatting. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> 2007-10-16 04:28:21 +07:00
			`#define tlb_start_vma(tlb, vma) do { } while (0)`
			`#define tlb_end_vma(tlb, vma) do { } while (0)`
			`#define __tlb_remove_tlb_entry(tlb, ptep, address) do { } while (0)`
x86/tlb: enable tlb flush range support for x86 Not every tlb_flush execution moment is really need to evacuate all TLB entries, like in munmap, just few 'invlpg' is better for whole process performance, since it leaves most of TLB entries for later accessing. This patch also rewrite flush_tlb_range for 2 purposes: 1, split it out to get flush_blt_mm_range function. 2, clean up to reduce line breaking, thanks for Borislav's input. My micro benchmark 'mummap' http://lkml.org/lkml/2012/5/17/59 show that the random memory access on other CPU has 0~50% speed up on a 2P * 4cores * HT NHM EP while do 'munmap'. Thanks Yongjie's testing on this patch: ------------- I used Linux 3.4-RC6 w/ and w/o his patches as Xen dom0 and guest kernel. After running two benchmarks in Xen HVM guest, I found his patches brought about 1%~3% performance gain in 'kernel build' and 'netperf' testing, though the performance gain was not very stable in 'kernel build' testing. Some detailed testing results are below. Testing Environment: Hardware: Romley-EP platform Xen version: latest upstream Linux kernel: 3.4-RC6 Guest vCPU number: 8 NIC: Intel 82599 (10GB bandwidth) In 'kernel build' testing in guest: Command line \| performance gain make -j 4 \| 3.81% make -j 8 \| 0.37% make -j 16 \| -0.52% In 'netperf' testing, we tested TCP_STREAM with default socket size 16384 byte as large packet and 64 byte as small packet. I used several clients to add networking pressure, then 'netperf' server automatically generated several threads to response them. I also used large-size packet and small-size packet in the testing. Packet size \| Thread number \| performance gain 16384 bytes \| 4 \| 0.02% 16384 bytes \| 8 \| 2.21% 16384 bytes \| 16 \| 2.04% 64 bytes \| 4 \| 1.07% 64 bytes \| 8 \| 3.31% 64 bytes \| 16 \| 0.71% Signed-off-by: Alex Shi <alex.shi@intel.com> Link: http://lkml.kernel.org/r/1340845344-27557-8-git-send-email-alex.shi@intel.com Tested-by: Ren, Yongjie <yongjie.ren@intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> 2012-06-28 08:02:22 +07:00
			`#define tlb_flush(tlb) \`
			`{ \`
x86-32: Fix possible incomplete TLB invalidate with PAE pagetables This patch attempts to fix: https://bugzilla.kernel.org/show_bug.cgi?id=56461 The symptom is a crash and messages like this: chrome: Corrupted page table at address 34a03000 pdpt = 0000000000000000 pde = 0000000000000000 Bad pagetable: 000f [#1] PREEMPT SMP Ingo guesses this got introduced by commit 611ae8e3f520 ("x86/tlb: enable tlb flush range support for x86") since that code started to free unused pagetables. On x86-32 PAE kernels, that new code has the potential to free an entire PMD page and will clear one of the four page-directory-pointer-table (aka pgd_t entries). The hardware aggressively "caches" these top-level entries and invlpg does not actually affect the CPU's copy. If we clear one we HAVE to do a full TLB flush, otherwise we might continue using a freed pmd page. (note, we do this properly on the population side in pud_populate()). This patch tracks whenever we clear one of these entries in the 'struct mmu_gather', and ensures that we follow up with a full tlb flush. BTW, I disassembled and checked that: if (tlb->fullmm == 0) and if (!tlb->fullmm && !tlb->need_flush_all) generate essentially the same code, so there should be zero impact there to the !PAE case. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Peter Anvin <hpa@zytor.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Artem S Tashkinov <t.artem@mailcity.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2013-04-13 06:23:54 +07:00			`if (!tlb->fullmm && !tlb->need_flush_all) \`
x86/tlb: enable tlb flush range support for x86 Not every tlb_flush execution moment is really need to evacuate all TLB entries, like in munmap, just few 'invlpg' is better for whole process performance, since it leaves most of TLB entries for later accessing. This patch also rewrite flush_tlb_range for 2 purposes: 1, split it out to get flush_blt_mm_range function. 2, clean up to reduce line breaking, thanks for Borislav's input. My micro benchmark 'mummap' http://lkml.org/lkml/2012/5/17/59 show that the random memory access on other CPU has 0~50% speed up on a 2P * 4cores * HT NHM EP while do 'munmap'. Thanks Yongjie's testing on this patch: ------------- I used Linux 3.4-RC6 w/ and w/o his patches as Xen dom0 and guest kernel. After running two benchmarks in Xen HVM guest, I found his patches brought about 1%~3% performance gain in 'kernel build' and 'netperf' testing, though the performance gain was not very stable in 'kernel build' testing. Some detailed testing results are below. Testing Environment: Hardware: Romley-EP platform Xen version: latest upstream Linux kernel: 3.4-RC6 Guest vCPU number: 8 NIC: Intel 82599 (10GB bandwidth) In 'kernel build' testing in guest: Command line \| performance gain make -j 4 \| 3.81% make -j 8 \| 0.37% make -j 16 \| -0.52% In 'netperf' testing, we tested TCP_STREAM with default socket size 16384 byte as large packet and 64 byte as small packet. I used several clients to add networking pressure, then 'netperf' server automatically generated several threads to response them. I also used large-size packet and small-size packet in the testing. Packet size \| Thread number \| performance gain 16384 bytes \| 4 \| 0.02% 16384 bytes \| 8 \| 2.21% 16384 bytes \| 16 \| 2.04% 64 bytes \| 4 \| 1.07% 64 bytes \| 8 \| 3.31% 64 bytes \| 16 \| 0.71% Signed-off-by: Alex Shi <alex.shi@intel.com> Link: http://lkml.kernel.org/r/1340845344-27557-8-git-send-email-alex.shi@intel.com Tested-by: Ren, Yongjie <yongjie.ren@intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> 2012-06-28 08:02:22 +07:00			`flush_tlb_mm_range(tlb->mm, tlb->start, tlb->end, 0UL); \`
			`else \`
			`flush_tlb_mm_range(tlb->mm, 0UL, TLB_FLUSH_ALL, 0UL); \`
			`}`
x86: unify include/asm/tlb_32/64.h Same file, except for whitespace, comment formatting. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> 2007-10-16 04:28:21 +07:00
			`#include <asm-generic/tlb.h>`

x86: Fix ASM_X86__ header guards Change header guards named "ASM_X86__" to "_ASM_X86_" since: a. the double underscore is ugly and pointless. b. no leading underscore violates namespace constraints. Signed-off-by: H. Peter Anvin <hpa@zytor.com> 2008-10-23 12:26:29 +07:00			`#endif /* _ASM_X86_TLB_H */`