* [PATCH 1/3] x86/tlb_info: get last level TLB entry number of CPU
@ 2012-04-28 8:50 Alex Shi
2012-04-28 8:50 ` [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range Alex Shi
2012-05-02 15:13 ` [PATCH 1/3] x86/tlb_info: get last level TLB entry number of CPU Rik van Riel
0 siblings, 2 replies; 17+ messages in thread
From: Alex Shi @ 2012-04-28 8:50 UTC (permalink / raw)
To: andi.kleen, tim.c.chen, jeremy, chrisw, akataria, tglx, mingo,
hpa, rostedt, fweisbec
Cc: riel, luto, alex.shi, avi, len.brown, paul.gortmaker, dhowells,
fenghua.yu, borislav.petkov, yinghai, cpw, steiner, linux-kernel
For 4KB pages, x86 CPU has 2 or 1 level TLB, first level is data TLB and
instruction TLB, second level is shared TLB for both data and instructions.
For hupe page TLB, usually there is just one level and seperated by 2MB/4MB
and 1GB.
Although each levels TLB size is important for performance tuning, but for
genernal and rude optimizing, just last level TLB entry number is suitable.
And in fact, last level TLB has the biggest entry number.
This patch will get the biggest TLB entry number and use it in furture TLB
optimizing.
Signed-off-by: Alex Shi <alex.shi@intel.com>
---
arch/x86/include/asm/processor.h | 12 +++
arch/x86/kernel/cpu/common.c | 163 ++++++++++++++++++++++++++++++++++++++
arch/x86/kernel/cpu/cpu.h | 1 +
3 files changed, 176 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 4fa7dcc..a91504b 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -61,6 +61,18 @@ static inline void *current_text_addr(void)
# define ARCH_MIN_MMSTRUCT_ALIGN 0
#endif
+enum tlb_infos {
+ ENTRIES,
+ /* ASS_WAYS, */
+ NR_INFO
+};
+
+extern u16 __read_mostly tlb_lli_4k[NR_INFO];
+extern u16 __read_mostly tlb_lli_2m[NR_INFO];
+extern u16 __read_mostly tlb_lli_4m[NR_INFO];
+extern u16 __read_mostly tlb_lld_4k[NR_INFO];
+extern u16 __read_mostly tlb_lld_2m[NR_INFO];
+extern u16 __read_mostly tlb_lld_4m[NR_INFO];
/*
* CPU type and hardware bug flags. Kept separately for each CPU.
* Members of this structure are referenced in head.S, so think twice
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index cf79302..5f14a70 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -452,6 +452,167 @@ void __cpuinit cpu_detect_cache_sizes(struct cpuinfo_x86 *c)
c->x86_cache_size = l2size;
}
+#define TLB_INST_4K 0x01
+#define TLB_INST_4M 0x02
+#define TLB_INST_2M_4M 0x03
+
+#define TLB_INST_ALL 0x05
+#define TLB_INST_1G 0x06
+
+#define TLB_DATA_4K 0x11
+#define TLB_DATA_4M 0x12
+#define TLB_DATA_2M_4M 0x13
+#define TLB_DATA_4K_4M 0x14
+
+#define TLB_DATA_1G 0x16
+
+#define TLB_DATA0_4K 0x21
+#define TLB_DATA0_4M 0x22
+#define TLB_DATA0_2M_4M 0x23
+
+#define STLB_4K 0x41
+
+struct _tlb_table {
+ unsigned char descriptor;
+ char tlb_type;
+ unsigned int entries;
+ /* unsigned int ways; */
+ char info[128];
+};
+
+static const struct _tlb_table tlb_table[] = {
+ { 0x01, TLB_INST_4K, 32, " TLB_INST 4 KByte pages, 4-way set associative" },
+ { 0x02, TLB_INST_4M, 2, " TLB_INST 4 MByte pages, full associative" },
+ { 0x03, TLB_DATA_4K, 64, " TLB_DATA 4 KByte pages, 4-way set associative" },
+ { 0x04, TLB_DATA_4M, 8, " TLB_DATA 4 MByte pages, 4-way set associative" },
+ { 0x05, TLB_DATA_4M, 32, " TLB_DATA 4 MByte pages, 4-way set associative" },
+ { 0x0b, TLB_INST_4M, 4, " TLB_INST 4 MByte pages, 4-way set associative" },
+ { 0x4f, TLB_INST_4K, 32, " TLB_INST 4 KByte pages */" },
+ { 0x50, TLB_INST_ALL, 64, " TLB_INST 4 KByte and 2-MByte or 4-MByte pages" },
+ { 0x51, TLB_INST_ALL, 128, " TLB_INST 4 KByte and 2-MByte or 4-MByte pages" },
+ { 0x52, TLB_INST_ALL, 256, " TLB_INST 4 KByte and 2-MByte or 4-MByte pages" },
+ { 0x55, TLB_INST_2M_4M, 7, " TLB_INST 2-MByte or 4-MByte pages, fully associative" },
+ { 0x56, TLB_DATA0_4M, 16, " TLB_DATA0 4 MByte pages, 4-way set associative" },
+ { 0x57, TLB_DATA0_4K, 16, " TLB_DATA0 4 KByte pages, 4-way associative" },
+ { 0x59, TLB_DATA0_4K, 16, " TLB_DATA0 4 KByte pages, fully associative" },
+ { 0x5a, TLB_DATA0_2M_4M, 32, " TLB_DATA0 2-MByte or 4 MByte pages, 4-way set associative" },
+ { 0x5b, TLB_DATA_4K_4M, 64, " TLB_DATA 4 KByte and 4 MByte pages" },
+ { 0x5c, TLB_DATA_4K_4M, 128, " TLB_DATA 4 KByte and 4 MByte pages" },
+ { 0x5d, TLB_DATA_4K_4M, 256, " TLB_DATA 4 KByte and 4 MByte pages" },
+ { 0xb0, TLB_INST_4K, 128, " TLB_INST 4 KByte pages, 4-way set associative" },
+ { 0xb1, TLB_INST_2M_4M, 4, " TLB_INST 2M pages, 4-way, 8 entries or 4M pages, 4-way entries" },
+ { 0xb2, TLB_INST_4K, 64, " TLB_INST 4KByte pages, 4-way set associative" },
+ { 0xb3, TLB_DATA_4K, 128, " TLB_DATA 4 KByte pages, 4-way set associative" },
+ { 0xb4, TLB_DATA_4K, 256, " TLB_DATA 4 KByte pages, 4-way associative" },
+ { 0xba, TLB_DATA_4K, 64, " TLB_DATA 4 KByte pages, 4-way associative" },
+ { 0xc0, TLB_DATA_4K_4M, 8, " TLB_DATA 4 KByte and 4 MByte pages, 4-way associative" },
+ { 0xca, STLB_4K, 512, " STLB 4 KByte pages, 4-way associative" },
+ { 0x00, 0, 0 }
+};
+
+u16 __read_mostly tlb_lli_4k[NR_INFO];
+u16 __read_mostly tlb_lli_2m[NR_INFO];
+u16 __read_mostly tlb_lli_4m[NR_INFO];
+u16 __read_mostly tlb_lld_4k[NR_INFO];
+u16 __read_mostly tlb_lld_2m[NR_INFO];
+u16 __read_mostly tlb_lld_4m[NR_INFO];
+
+void tlb_lookup(const unsigned char desc)
+{
+ unsigned char k;
+ if (desc == 0)
+ return;
+
+ /* look up this descriptor in the table */
+ for (k = 0; tlb_table[k].descriptor != desc && \
+ tlb_table[k].descriptor != 0; k++)
+ ;
+
+ if (tlb_table[k].tlb_type == 0)
+ return;
+
+ switch (tlb_table[k].tlb_type) {
+ case STLB_4K:
+ if (tlb_lli_4k[ENTRIES] < tlb_table[k].entries)
+ tlb_lli_4k[ENTRIES] = tlb_table[k].entries;
+ if (tlb_lld_4k[ENTRIES] < tlb_table[k].entries)
+ tlb_lld_4k[ENTRIES] = tlb_table[k].entries;
+ break;
+ case TLB_INST_ALL:
+ if (tlb_lli_4k[ENTRIES] < tlb_table[k].entries)
+ tlb_lli_4k[ENTRIES] = tlb_table[k].entries;
+ if (tlb_lli_2m[ENTRIES] < tlb_table[k].entries)
+ tlb_lli_2m[ENTRIES] = tlb_table[k].entries;
+ if (tlb_lli_4m[ENTRIES] < tlb_table[k].entries)
+ tlb_lli_4m[ENTRIES] = tlb_table[k].entries;
+ break;
+ case TLB_INST_4K:
+ if (tlb_lli_4k[ENTRIES] < tlb_table[k].entries)
+ tlb_lli_4k[ENTRIES] = tlb_table[k].entries;
+ break;
+ case TLB_INST_4M:
+ if (tlb_lli_4m[ENTRIES] < tlb_table[k].entries)
+ tlb_lli_4m[ENTRIES] = tlb_table[k].entries;
+ break;
+ case TLB_INST_2M_4M:
+ if (tlb_lli_2m[ENTRIES] < tlb_table[k].entries)
+ tlb_lli_2m[ENTRIES] = tlb_table[k].entries;
+ if (tlb_lli_4m[ENTRIES] < tlb_table[k].entries)
+ tlb_lli_4m[ENTRIES] = tlb_table[k].entries;
+ break;
+ case TLB_DATA_4K:
+ case TLB_DATA0_4K:
+ if (tlb_lld_4k[ENTRIES] < tlb_table[k].entries)
+ tlb_lld_4k[ENTRIES] = tlb_table[k].entries;
+ break;
+ case TLB_DATA_4M:
+ case TLB_DATA0_4M:
+ if (tlb_lld_4m[ENTRIES] < tlb_table[k].entries)
+ tlb_lld_4m[ENTRIES] = tlb_table[k].entries;
+ break;
+ case TLB_DATA_2M_4M:
+ case TLB_DATA0_2M_4M:
+ if (tlb_lld_2m[ENTRIES] < tlb_table[k].entries)
+ tlb_lld_2m[ENTRIES] = tlb_table[k].entries;
+ if (tlb_lld_4m[ENTRIES] < tlb_table[k].entries)
+ tlb_lld_4m[ENTRIES] = tlb_table[k].entries;
+ break;
+ case TLB_DATA_4K_4M:
+ if (tlb_lld_4k[ENTRIES] < tlb_table[k].entries)
+ tlb_lld_4k[ENTRIES] = tlb_table[k].entries;
+ if (tlb_lld_4m[ENTRIES] < tlb_table[k].entries)
+ tlb_lld_4m[ENTRIES] = tlb_table[k].entries;
+ break;
+ }
+}
+void __cpuinit cpu_detect_tlb_sizes()
+{
+ int i, j, n;
+ unsigned int regs[4];
+ unsigned char *desc = (unsigned char *)regs;
+
+ /* Number of times to iterate */
+ n = cpuid_eax(2) & 0xFF;
+
+ for (i = 0 ; i < n ; i++) {
+ cpuid(2, ®s[0], ®s[1], ®s[2], ®s[3]);
+
+ /* If bit 31 is set, this is an unknown format */
+ for (j = 0 ; j < 3 ; j++)
+ if (regs[j] & (1 << 31))
+ regs[j] = 0;
+
+ /* Byte 0 is level count, not a descriptor */
+ for (j = 1 ; j < 16 ; j++)
+ tlb_lookup(desc[j]);
+ }
+ printk(KERN_INFO "Last level iTLB entries: 4KB %d, 2MB %d, 4MB %d\n" \
+ "Last level dTLB entires: 4KB %d, 2MB %d, 4MB %d\n",
+ tlb_lli_4k[ENTRIES], tlb_lli_2m[ENTRIES],
+ tlb_lli_4m[ENTRIES], tlb_lld_4k[ENTRIES],
+ tlb_lld_2m[ENTRIES], tlb_lld_4m[ENTRIES]);
+}
+
void __cpuinit detect_ht(struct cpuinfo_x86 *c)
{
#ifdef CONFIG_X86_HT
@@ -911,6 +1072,8 @@ void __init identify_boot_cpu(void)
#else
vgetcpu_set_mode();
#endif
+ if (boot_cpu_data.cpuid_level >= 2)
+ cpu_detect_tlb_sizes();
}
void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c)
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index 8bacc78..a102ed1 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -34,4 +34,5 @@ extern const struct cpu_dev *const __x86_cpu_dev_start[],
extern void get_cpu_cap(struct cpuinfo_x86 *c);
extern void cpu_detect_cache_sizes(struct cpuinfo_x86 *c);
+extern void cpu_detect_tlb_sizes(void);
#endif /* ARCH_X86_CPU_H */
--
1.7.5.4
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-04-28 8:50 [PATCH 1/3] x86/tlb_info: get last level TLB entry number of CPU Alex Shi
@ 2012-04-28 8:50 ` Alex Shi
2012-05-02 15:21 ` Rik van Riel
2012-05-02 15:13 ` [PATCH 1/3] x86/tlb_info: get last level TLB entry number of CPU Rik van Riel
1 sibling, 1 reply; 17+ messages in thread
From: Alex Shi @ 2012-04-28 8:50 UTC (permalink / raw)
To: andi.kleen, tim.c.chen, jeremy, chrisw, akataria, tglx, mingo,
hpa, rostedt, fweisbec
Cc: riel, luto, alex.shi, avi, len.brown, paul.gortmaker, dhowells,
fenghua.yu, borislav.petkov, yinghai, cpw, steiner, linux-kernel
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 * 100ns(assumed TLB refill cost) =
x(TLB flush entries) * 140ns(assumed invlpg cost)
Here, x is about 360, that is about 5/8 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 macro 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 27ns
./mprotect -t 32 54ns 52ns
./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
I also tried other benchmarks on Intel core2/NHM/SNB EP and NHM EX machine.
No clear performance change on specjbb2005 with openjdk, and oltp reading.
Signed-off-by: Alex Shi <alex.shi@intel.com>
---
arch/x86/include/asm/paravirt.h | 5 +-
arch/x86/include/asm/paravirt_types.h | 3 +-
arch/x86/include/asm/tlbflush.h | 19 +++----
arch/x86/include/asm/uv/uv.h | 5 +-
arch/x86/mm/tlb.c | 97 +++++++++++++++++++++++++++------
arch/x86/platform/uv/tlb_uv.c | 6 +-
arch/x86/xen/mmu.c | 9 ++--
include/trace/events/xen.h | 12 +++--
8 files changed, 113 insertions(+), 43 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index aa0f913..03da4ab 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -397,9 +397,10 @@ static inline void __flush_tlb_single(unsigned long addr)
static inline void flush_tlb_others(const struct cpumask *cpumask,
struct mm_struct *mm,
- unsigned long va)
+ unsigned long start,
+ unsigned long end)
{
- PVOP_VCALL3(pv_mmu_ops.flush_tlb_others, cpumask, mm, va);
+ PVOP_VCALL4(pv_mmu_ops.flush_tlb_others, cpumask, mm, start, end);
}
static inline int paravirt_pgd_alloc(struct mm_struct *mm)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 8e8b9a4..600a5fcac9 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -250,7 +250,8 @@ struct pv_mmu_ops {
void (*flush_tlb_single)(unsigned long addr);
void (*flush_tlb_others)(const struct cpumask *cpus,
struct mm_struct *mm,
- unsigned long va);
+ unsigned long start,
+ unsigned long end);
/* Hooks for allocating and freeing a pagetable top-level */
int (*pgd_alloc)(struct mm_struct *mm);
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index c0e108e..ec30dfb 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -77,7 +77,7 @@ static inline void __flush_tlb_one(unsigned long addr)
* - flush_tlb_page(vma, vmaddr) flushes one page
* - flush_tlb_range(vma, start, end) flushes a range of pages
* - flush_tlb_kernel_range(start, end) flushes a range of kernel pages
- * - flush_tlb_others(cpumask, mm, va) flushes TLBs on other cpus
+ * - flush_tlb_others(cpumask, mm, start, end) flushes TLBs on other cpus
*
* ..but the i386 has somewhat limited tlb flushing capabilities,
* and page-granular flushes are available only on i486 and up.
@@ -115,7 +115,8 @@ static inline void flush_tlb_range(struct vm_area_struct *vma,
static inline void native_flush_tlb_others(const struct cpumask *cpumask,
struct mm_struct *mm,
- unsigned long va)
+ unsigned long start,
+ unsigned long end)
{
}
@@ -133,17 +134,14 @@ extern void flush_tlb_all(void);
extern void flush_tlb_current_task(void);
extern void flush_tlb_mm(struct mm_struct *);
extern void flush_tlb_page(struct vm_area_struct *, unsigned long);
+extern void flush_tlb_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end);
#define flush_tlb() flush_tlb_current_task()
-static inline void flush_tlb_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end)
-{
- flush_tlb_mm(vma->vm_mm);
-}
-
void native_flush_tlb_others(const struct cpumask *cpumask,
- struct mm_struct *mm, unsigned long va);
+ struct mm_struct *mm,
+ unsigned long start, unsigned long end);
#define TLBSTATE_OK 1
#define TLBSTATE_LAZY 2
@@ -163,7 +161,8 @@ static inline void reset_lazy_tlbstate(void)
#endif /* SMP */
#ifndef CONFIG_PARAVIRT
-#define flush_tlb_others(mask, mm, va) native_flush_tlb_others(mask, mm, va)
+#define flush_tlb_others(mask, mm, start, end) \
+ native_flush_tlb_others(mask, mm, start, end)
#endif
static inline void flush_tlb_kernel_range(unsigned long start,
diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
index 3bb9491..b47c2a8 100644
--- a/arch/x86/include/asm/uv/uv.h
+++ b/arch/x86/include/asm/uv/uv.h
@@ -15,7 +15,8 @@ extern void uv_nmi_init(void);
extern void uv_system_init(void);
extern const struct cpumask *uv_flush_tlb_others(const struct cpumask *cpumask,
struct mm_struct *mm,
- unsigned long va,
+ unsigned long start,
+ unsigned end,
unsigned int cpu);
#else /* X86_UV */
@@ -26,7 +27,7 @@ static inline void uv_cpu_init(void) { }
static inline void uv_system_init(void) { }
static inline const struct cpumask *
uv_flush_tlb_others(const struct cpumask *cpumask, struct mm_struct *mm,
- unsigned long va, unsigned int cpu)
+ unsigned long start, unsigned long end, unsigned int cpu)
{ return cpumask; }
#endif /* X86_UV */
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index d6c0418..c4e694d 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -41,7 +41,8 @@ DEFINE_PER_CPU_SHARED_ALIGNED(struct tlb_state, cpu_tlbstate)
union smp_flush_state {
struct {
struct mm_struct *flush_mm;
- unsigned long flush_va;
+ unsigned long flush_start;
+ unsigned long flush_end;
raw_spinlock_t tlbstate_lock;
DECLARE_BITMAP(flush_cpumask, NR_CPUS);
};
@@ -154,10 +155,19 @@ void smp_invalidate_interrupt(struct pt_regs *regs)
if (f->flush_mm == percpu_read(cpu_tlbstate.active_mm)) {
if (percpu_read(cpu_tlbstate.state) == TLBSTATE_OK) {
- if (f->flush_va == TLB_FLUSH_ALL)
+ if (f->flush_start == TLB_FLUSH_ALL
+ || !cpu_has_invlpg)
local_flush_tlb();
- else
- __flush_tlb_one(f->flush_va);
+ else if (!f->flush_end)
+ __flush_tlb_single(f->flush_start);
+ else {
+ unsigned long addr;
+ addr = f->flush_start;
+ while (addr <= f->flush_end) {
+ __flush_tlb_single(addr);
+ addr += PAGE_SIZE;
+ }
+ }
} else
leave_mm(cpu);
}
@@ -170,7 +180,8 @@ out:
}
static void flush_tlb_others_ipi(const struct cpumask *cpumask,
- struct mm_struct *mm, unsigned long va)
+ struct mm_struct *mm, unsigned long start,
+ unsigned long end)
{
unsigned int sender;
union smp_flush_state *f;
@@ -183,7 +194,8 @@ static void flush_tlb_others_ipi(const struct cpumask *cpumask,
raw_spin_lock(&f->tlbstate_lock);
f->flush_mm = mm;
- f->flush_va = va;
+ f->flush_start = start;
+ f->flush_end = end;
if (cpumask_andnot(to_cpumask(f->flush_cpumask), cpumask, cpumask_of(smp_processor_id()))) {
/*
* We have to send the IPI only to
@@ -197,24 +209,26 @@ static void flush_tlb_others_ipi(const struct cpumask *cpumask,
}
f->flush_mm = NULL;
- f->flush_va = 0;
+ f->flush_start = 0;
+ f->flush_end = 0;
if (nr_cpu_ids > NUM_INVALIDATE_TLB_VECTORS)
raw_spin_unlock(&f->tlbstate_lock);
}
void native_flush_tlb_others(const struct cpumask *cpumask,
- struct mm_struct *mm, unsigned long va)
+ struct mm_struct *mm, unsigned long start,
+ unsigned long end)
{
if (is_uv_system()) {
unsigned int cpu;
cpu = smp_processor_id();
- cpumask = uv_flush_tlb_others(cpumask, mm, va, cpu);
+ cpumask = uv_flush_tlb_others(cpumask, mm, start, end, cpu);
if (cpumask)
- flush_tlb_others_ipi(cpumask, mm, va);
+ flush_tlb_others_ipi(cpumask, mm, start, end);
return;
}
- flush_tlb_others_ipi(cpumask, mm, va);
+ flush_tlb_others_ipi(cpumask, mm, start, end);
}
static void __cpuinit calculate_tlb_offset(void)
@@ -280,7 +294,7 @@ void flush_tlb_current_task(void)
local_flush_tlb();
if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
- flush_tlb_others(mm_cpumask(mm), mm, TLB_FLUSH_ALL);
+ flush_tlb_others(mm_cpumask(mm), mm, TLB_FLUSH_ALL, 0UL);
preempt_enable();
}
@@ -295,12 +309,63 @@ void flush_tlb_mm(struct mm_struct *mm)
leave_mm(smp_processor_id());
}
if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
- flush_tlb_others(mm_cpumask(mm), mm, TLB_FLUSH_ALL);
+ flush_tlb_others(mm_cpumask(mm), mm, TLB_FLUSH_ALL, 0UL);
+
+ preempt_enable();
+}
+
+#define FLUSHALL_BAR 16
+
+void flush_tlb_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+ struct mm_struct *mm;
+
+ if (!cpu_has_invlpg || vma->vm_flags & VM_HUGETLB) {
+ flush_tlb_mm(vma->vm_mm);
+ return;
+ }
+
+ preempt_disable();
+ mm = vma->vm_mm;
+ if (current->active_mm == mm) {
+ if (current->mm) {
+ unsigned long addr, vmflag = vma->vm_flags;
+ unsigned act_entries, tlb_entries = 0;
+
+ if (vmflag & VM_EXEC)
+ tlb_entries = tlb_lli_4k[ENTRIES];
+ else
+ tlb_entries = tlb_lld_4k[ENTRIES];
+
+ act_entries = tlb_entries > mm->total_vm ?
+ mm->total_vm : tlb_entries;
+ if ((end - start)/PAGE_SIZE > act_entries/FLUSHALL_BAR)
+ local_flush_tlb();
+ else {
+ for (addr = start; addr <= end;
+ addr += PAGE_SIZE)
+ __flush_tlb_single(addr);
+
+ if (cpumask_any_but(mm_cpumask(mm),
+ smp_processor_id()) < nr_cpu_ids)
+ flush_tlb_others(mm_cpumask(mm), mm,
+ start, end);
+ preempt_enable();
+ return;
+ }
+ } else {
+ leave_mm(smp_processor_id());
+ }
+ }
+ if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
+ flush_tlb_others(mm_cpumask(mm), mm, TLB_FLUSH_ALL, 0UL);
preempt_enable();
}
-void flush_tlb_page(struct vm_area_struct *vma, unsigned long va)
+
+void flush_tlb_page(struct vm_area_struct *vma, unsigned long start)
{
struct mm_struct *mm = vma->vm_mm;
@@ -308,13 +373,13 @@ void flush_tlb_page(struct vm_area_struct *vma, unsigned long va)
if (current->active_mm == mm) {
if (current->mm)
- __flush_tlb_one(va);
+ __flush_tlb_one(start);
else
leave_mm(smp_processor_id());
}
if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
- flush_tlb_others(mm_cpumask(mm), mm, va);
+ flush_tlb_others(mm_cpumask(mm), mm, start, 0UL);
preempt_enable();
}
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index 3ae0e61..0df5ad2 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -1068,8 +1068,8 @@ static int set_distrib_bits(struct cpumask *flush_mask, struct bau_control *bcp,
* done. The returned pointer is valid till preemption is re-enabled.
*/
const struct cpumask *uv_flush_tlb_others(const struct cpumask *cpumask,
- struct mm_struct *mm, unsigned long va,
- unsigned int cpu)
+ struct mm_struct *mm, unsigned long start,
+ unsigned end, unsigned int cpu)
{
int locals = 0;
int remotes = 0;
@@ -1112,7 +1112,7 @@ const struct cpumask *uv_flush_tlb_others(const struct cpumask *cpumask,
record_send_statistics(stat, locals, hubs, remotes, bau_desc);
- bau_desc->payload.address = va;
+ bau_desc->payload.address = start;
bau_desc->payload.sending_cpu = cpu;
/*
* uv_flush_send_and_wait returns 0 if all cpu's were messaged,
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index b8e2794..75bab52 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1239,7 +1239,8 @@ static void xen_flush_tlb_single(unsigned long addr)
}
static void xen_flush_tlb_others(const struct cpumask *cpus,
- struct mm_struct *mm, unsigned long va)
+ struct mm_struct *mm, unsigned long start,
+ unsigned long end)
{
struct {
struct mmuext_op op;
@@ -1251,7 +1252,7 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
} *args;
struct multicall_space mcs;
- trace_xen_mmu_flush_tlb_others(cpus, mm, va);
+ trace_xen_mmu_flush_tlb_others(cpus, mm, start, end);
if (cpumask_empty(cpus))
return; /* nothing to do */
@@ -1264,11 +1265,11 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));
- if (va == TLB_FLUSH_ALL) {
+ if (start == TLB_FLUSH_ALL) {
args->op.cmd = MMUEXT_TLB_FLUSH_MULTI;
} else {
args->op.cmd = MMUEXT_INVLPG_MULTI;
- args->op.arg1.linear_addr = va;
+ args->op.arg1.linear_addr = start;
}
MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);
diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
index 92f1a79..15ba03b 100644
--- a/include/trace/events/xen.h
+++ b/include/trace/events/xen.h
@@ -397,18 +397,20 @@ TRACE_EVENT(xen_mmu_flush_tlb_single,
TRACE_EVENT(xen_mmu_flush_tlb_others,
TP_PROTO(const struct cpumask *cpus, struct mm_struct *mm,
- unsigned long addr),
- TP_ARGS(cpus, mm, addr),
+ unsigned long addr, unsigned long end),
+ TP_ARGS(cpus, mm, addr, end),
TP_STRUCT__entry(
__field(unsigned, ncpus)
__field(struct mm_struct *, mm)
__field(unsigned long, addr)
+ __field(unsigned long, end)
),
TP_fast_assign(__entry->ncpus = cpumask_weight(cpus);
__entry->mm = mm;
- __entry->addr = addr),
- TP_printk("ncpus %d mm %p addr %lx",
- __entry->ncpus, __entry->mm, __entry->addr)
+ __entry->addr = addr,
+ __entry->end = end),
+ TP_printk("ncpus %d mm %p addr %lx, end %lx",
+ __entry->ncpus, __entry->mm, __entry->addr, __entry->end)
);
TRACE_EVENT(xen_mmu_write_cr3,
--
1.7.5.4
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-04-28 8:51 [PATCH 0/3] TLB flush range optimization Alex Shi
@ 2012-04-28 8:51 ` Alex Shi
2012-04-30 10:54 ` Borislav Petkov
2012-05-04 2:24 ` Ren, Yongjie
0 siblings, 2 replies; 17+ messages in thread
From: Alex Shi @ 2012-04-28 8:51 UTC (permalink / raw)
To: andi.kleen, tim.c.chen, jeremy, chrisw, akataria, tglx, mingo,
hpa, rostedt, fweisbec
Cc: riel, luto, alex.shi, avi, len.brown, paul.gortmaker, dhowells,
fenghua.yu, borislav.petkov, yinghai, cpw, steiner, linux-kernel,
yongjie.ren
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 * 100ns(assumed TLB refill cost) =
x(TLB flush entries) * 140ns(assumed invlpg cost)
Here, x is about 360, that is about 5/8 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 macro 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 27ns
./mprotect -t 32 54ns 52ns
./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
I also tried other benchmarks on Intel core2/NHM/SNB EP and NHM EX machine.
No clear performance change on specjbb2005 with openjdk, and oltp reading.
Signed-off-by: Alex Shi <alex.shi@intel.com>
---
arch/x86/include/asm/paravirt.h | 5 +-
arch/x86/include/asm/paravirt_types.h | 3 +-
arch/x86/include/asm/tlbflush.h | 19 +++----
arch/x86/include/asm/uv/uv.h | 5 +-
arch/x86/mm/tlb.c | 97 +++++++++++++++++++++++++++------
arch/x86/platform/uv/tlb_uv.c | 6 +-
arch/x86/xen/mmu.c | 9 ++--
include/trace/events/xen.h | 12 +++--
8 files changed, 113 insertions(+), 43 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index aa0f913..03da4ab 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -397,9 +397,10 @@ static inline void __flush_tlb_single(unsigned long addr)
static inline void flush_tlb_others(const struct cpumask *cpumask,
struct mm_struct *mm,
- unsigned long va)
+ unsigned long start,
+ unsigned long end)
{
- PVOP_VCALL3(pv_mmu_ops.flush_tlb_others, cpumask, mm, va);
+ PVOP_VCALL4(pv_mmu_ops.flush_tlb_others, cpumask, mm, start, end);
}
static inline int paravirt_pgd_alloc(struct mm_struct *mm)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 8e8b9a4..600a5fcac9 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -250,7 +250,8 @@ struct pv_mmu_ops {
void (*flush_tlb_single)(unsigned long addr);
void (*flush_tlb_others)(const struct cpumask *cpus,
struct mm_struct *mm,
- unsigned long va);
+ unsigned long start,
+ unsigned long end);
/* Hooks for allocating and freeing a pagetable top-level */
int (*pgd_alloc)(struct mm_struct *mm);
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index c0e108e..ec30dfb 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -77,7 +77,7 @@ static inline void __flush_tlb_one(unsigned long addr)
* - flush_tlb_page(vma, vmaddr) flushes one page
* - flush_tlb_range(vma, start, end) flushes a range of pages
* - flush_tlb_kernel_range(start, end) flushes a range of kernel pages
- * - flush_tlb_others(cpumask, mm, va) flushes TLBs on other cpus
+ * - flush_tlb_others(cpumask, mm, start, end) flushes TLBs on other cpus
*
* ..but the i386 has somewhat limited tlb flushing capabilities,
* and page-granular flushes are available only on i486 and up.
@@ -115,7 +115,8 @@ static inline void flush_tlb_range(struct vm_area_struct *vma,
static inline void native_flush_tlb_others(const struct cpumask *cpumask,
struct mm_struct *mm,
- unsigned long va)
+ unsigned long start,
+ unsigned long end)
{
}
@@ -133,17 +134,14 @@ extern void flush_tlb_all(void);
extern void flush_tlb_current_task(void);
extern void flush_tlb_mm(struct mm_struct *);
extern void flush_tlb_page(struct vm_area_struct *, unsigned long);
+extern void flush_tlb_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end);
#define flush_tlb() flush_tlb_current_task()
-static inline void flush_tlb_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end)
-{
- flush_tlb_mm(vma->vm_mm);
-}
-
void native_flush_tlb_others(const struct cpumask *cpumask,
- struct mm_struct *mm, unsigned long va);
+ struct mm_struct *mm,
+ unsigned long start, unsigned long end);
#define TLBSTATE_OK 1
#define TLBSTATE_LAZY 2
@@ -163,7 +161,8 @@ static inline void reset_lazy_tlbstate(void)
#endif /* SMP */
#ifndef CONFIG_PARAVIRT
-#define flush_tlb_others(mask, mm, va) native_flush_tlb_others(mask, mm, va)
+#define flush_tlb_others(mask, mm, start, end) \
+ native_flush_tlb_others(mask, mm, start, end)
#endif
static inline void flush_tlb_kernel_range(unsigned long start,
diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
index 3bb9491..b47c2a8 100644
--- a/arch/x86/include/asm/uv/uv.h
+++ b/arch/x86/include/asm/uv/uv.h
@@ -15,7 +15,8 @@ extern void uv_nmi_init(void);
extern void uv_system_init(void);
extern const struct cpumask *uv_flush_tlb_others(const struct cpumask *cpumask,
struct mm_struct *mm,
- unsigned long va,
+ unsigned long start,
+ unsigned end,
unsigned int cpu);
#else /* X86_UV */
@@ -26,7 +27,7 @@ static inline void uv_cpu_init(void) { }
static inline void uv_system_init(void) { }
static inline const struct cpumask *
uv_flush_tlb_others(const struct cpumask *cpumask, struct mm_struct *mm,
- unsigned long va, unsigned int cpu)
+ unsigned long start, unsigned long end, unsigned int cpu)
{ return cpumask; }
#endif /* X86_UV */
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index d6c0418..c4e694d 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -41,7 +41,8 @@ DEFINE_PER_CPU_SHARED_ALIGNED(struct tlb_state, cpu_tlbstate)
union smp_flush_state {
struct {
struct mm_struct *flush_mm;
- unsigned long flush_va;
+ unsigned long flush_start;
+ unsigned long flush_end;
raw_spinlock_t tlbstate_lock;
DECLARE_BITMAP(flush_cpumask, NR_CPUS);
};
@@ -154,10 +155,19 @@ void smp_invalidate_interrupt(struct pt_regs *regs)
if (f->flush_mm == percpu_read(cpu_tlbstate.active_mm)) {
if (percpu_read(cpu_tlbstate.state) == TLBSTATE_OK) {
- if (f->flush_va == TLB_FLUSH_ALL)
+ if (f->flush_start == TLB_FLUSH_ALL
+ || !cpu_has_invlpg)
local_flush_tlb();
- else
- __flush_tlb_one(f->flush_va);
+ else if (!f->flush_end)
+ __flush_tlb_single(f->flush_start);
+ else {
+ unsigned long addr;
+ addr = f->flush_start;
+ while (addr <= f->flush_end) {
+ __flush_tlb_single(addr);
+ addr += PAGE_SIZE;
+ }
+ }
} else
leave_mm(cpu);
}
@@ -170,7 +180,8 @@ out:
}
static void flush_tlb_others_ipi(const struct cpumask *cpumask,
- struct mm_struct *mm, unsigned long va)
+ struct mm_struct *mm, unsigned long start,
+ unsigned long end)
{
unsigned int sender;
union smp_flush_state *f;
@@ -183,7 +194,8 @@ static void flush_tlb_others_ipi(const struct cpumask *cpumask,
raw_spin_lock(&f->tlbstate_lock);
f->flush_mm = mm;
- f->flush_va = va;
+ f->flush_start = start;
+ f->flush_end = end;
if (cpumask_andnot(to_cpumask(f->flush_cpumask), cpumask, cpumask_of(smp_processor_id()))) {
/*
* We have to send the IPI only to
@@ -197,24 +209,26 @@ static void flush_tlb_others_ipi(const struct cpumask *cpumask,
}
f->flush_mm = NULL;
- f->flush_va = 0;
+ f->flush_start = 0;
+ f->flush_end = 0;
if (nr_cpu_ids > NUM_INVALIDATE_TLB_VECTORS)
raw_spin_unlock(&f->tlbstate_lock);
}
void native_flush_tlb_others(const struct cpumask *cpumask,
- struct mm_struct *mm, unsigned long va)
+ struct mm_struct *mm, unsigned long start,
+ unsigned long end)
{
if (is_uv_system()) {
unsigned int cpu;
cpu = smp_processor_id();
- cpumask = uv_flush_tlb_others(cpumask, mm, va, cpu);
+ cpumask = uv_flush_tlb_others(cpumask, mm, start, end, cpu);
if (cpumask)
- flush_tlb_others_ipi(cpumask, mm, va);
+ flush_tlb_others_ipi(cpumask, mm, start, end);
return;
}
- flush_tlb_others_ipi(cpumask, mm, va);
+ flush_tlb_others_ipi(cpumask, mm, start, end);
}
static void __cpuinit calculate_tlb_offset(void)
@@ -280,7 +294,7 @@ void flush_tlb_current_task(void)
local_flush_tlb();
if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
- flush_tlb_others(mm_cpumask(mm), mm, TLB_FLUSH_ALL);
+ flush_tlb_others(mm_cpumask(mm), mm, TLB_FLUSH_ALL, 0UL);
preempt_enable();
}
@@ -295,12 +309,63 @@ void flush_tlb_mm(struct mm_struct *mm)
leave_mm(smp_processor_id());
}
if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
- flush_tlb_others(mm_cpumask(mm), mm, TLB_FLUSH_ALL);
+ flush_tlb_others(mm_cpumask(mm), mm, TLB_FLUSH_ALL, 0UL);
+
+ preempt_enable();
+}
+
+#define FLUSHALL_BAR 16
+
+void flush_tlb_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+ struct mm_struct *mm;
+
+ if (!cpu_has_invlpg || vma->vm_flags & VM_HUGETLB) {
+ flush_tlb_mm(vma->vm_mm);
+ return;
+ }
+
+ preempt_disable();
+ mm = vma->vm_mm;
+ if (current->active_mm == mm) {
+ if (current->mm) {
+ unsigned long addr, vmflag = vma->vm_flags;
+ unsigned act_entries, tlb_entries = 0;
+
+ if (vmflag & VM_EXEC)
+ tlb_entries = tlb_lli_4k[ENTRIES];
+ else
+ tlb_entries = tlb_lld_4k[ENTRIES];
+
+ act_entries = tlb_entries > mm->total_vm ?
+ mm->total_vm : tlb_entries;
+ if ((end - start)/PAGE_SIZE > act_entries/FLUSHALL_BAR)
+ local_flush_tlb();
+ else {
+ for (addr = start; addr <= end;
+ addr += PAGE_SIZE)
+ __flush_tlb_single(addr);
+
+ if (cpumask_any_but(mm_cpumask(mm),
+ smp_processor_id()) < nr_cpu_ids)
+ flush_tlb_others(mm_cpumask(mm), mm,
+ start, end);
+ preempt_enable();
+ return;
+ }
+ } else {
+ leave_mm(smp_processor_id());
+ }
+ }
+ if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
+ flush_tlb_others(mm_cpumask(mm), mm, TLB_FLUSH_ALL, 0UL);
preempt_enable();
}
-void flush_tlb_page(struct vm_area_struct *vma, unsigned long va)
+
+void flush_tlb_page(struct vm_area_struct *vma, unsigned long start)
{
struct mm_struct *mm = vma->vm_mm;
@@ -308,13 +373,13 @@ void flush_tlb_page(struct vm_area_struct *vma, unsigned long va)
if (current->active_mm == mm) {
if (current->mm)
- __flush_tlb_one(va);
+ __flush_tlb_one(start);
else
leave_mm(smp_processor_id());
}
if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
- flush_tlb_others(mm_cpumask(mm), mm, va);
+ flush_tlb_others(mm_cpumask(mm), mm, start, 0UL);
preempt_enable();
}
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index 3ae0e61..0df5ad2 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -1068,8 +1068,8 @@ static int set_distrib_bits(struct cpumask *flush_mask, struct bau_control *bcp,
* done. The returned pointer is valid till preemption is re-enabled.
*/
const struct cpumask *uv_flush_tlb_others(const struct cpumask *cpumask,
- struct mm_struct *mm, unsigned long va,
- unsigned int cpu)
+ struct mm_struct *mm, unsigned long start,
+ unsigned end, unsigned int cpu)
{
int locals = 0;
int remotes = 0;
@@ -1112,7 +1112,7 @@ const struct cpumask *uv_flush_tlb_others(const struct cpumask *cpumask,
record_send_statistics(stat, locals, hubs, remotes, bau_desc);
- bau_desc->payload.address = va;
+ bau_desc->payload.address = start;
bau_desc->payload.sending_cpu = cpu;
/*
* uv_flush_send_and_wait returns 0 if all cpu's were messaged,
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index b8e2794..75bab52 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1239,7 +1239,8 @@ static void xen_flush_tlb_single(unsigned long addr)
}
static void xen_flush_tlb_others(const struct cpumask *cpus,
- struct mm_struct *mm, unsigned long va)
+ struct mm_struct *mm, unsigned long start,
+ unsigned long end)
{
struct {
struct mmuext_op op;
@@ -1251,7 +1252,7 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
} *args;
struct multicall_space mcs;
- trace_xen_mmu_flush_tlb_others(cpus, mm, va);
+ trace_xen_mmu_flush_tlb_others(cpus, mm, start, end);
if (cpumask_empty(cpus))
return; /* nothing to do */
@@ -1264,11 +1265,11 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));
- if (va == TLB_FLUSH_ALL) {
+ if (start == TLB_FLUSH_ALL) {
args->op.cmd = MMUEXT_TLB_FLUSH_MULTI;
} else {
args->op.cmd = MMUEXT_INVLPG_MULTI;
- args->op.arg1.linear_addr = va;
+ args->op.arg1.linear_addr = start;
}
MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);
diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
index 92f1a79..15ba03b 100644
--- a/include/trace/events/xen.h
+++ b/include/trace/events/xen.h
@@ -397,18 +397,20 @@ TRACE_EVENT(xen_mmu_flush_tlb_single,
TRACE_EVENT(xen_mmu_flush_tlb_others,
TP_PROTO(const struct cpumask *cpus, struct mm_struct *mm,
- unsigned long addr),
- TP_ARGS(cpus, mm, addr),
+ unsigned long addr, unsigned long end),
+ TP_ARGS(cpus, mm, addr, end),
TP_STRUCT__entry(
__field(unsigned, ncpus)
__field(struct mm_struct *, mm)
__field(unsigned long, addr)
+ __field(unsigned long, end)
),
TP_fast_assign(__entry->ncpus = cpumask_weight(cpus);
__entry->mm = mm;
- __entry->addr = addr),
- TP_printk("ncpus %d mm %p addr %lx",
- __entry->ncpus, __entry->mm, __entry->addr)
+ __entry->addr = addr,
+ __entry->end = end),
+ TP_printk("ncpus %d mm %p addr %lx, end %lx",
+ __entry->ncpus, __entry->mm, __entry->addr, __entry->end)
);
TRACE_EVENT(xen_mmu_write_cr3,
--
1.7.5.4
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-04-28 8:51 ` [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range Alex Shi
@ 2012-04-30 10:54 ` Borislav Petkov
2012-05-02 9:24 ` Alex Shi
2012-05-04 2:24 ` Ren, Yongjie
1 sibling, 1 reply; 17+ messages in thread
From: Borislav Petkov @ 2012-04-30 10:54 UTC (permalink / raw)
To: Alex Shi
Cc: andi.kleen, tim.c.chen, jeremy, chrisw, akataria, tglx, mingo,
hpa, rostedt, fweisbec, riel, luto, avi, len.brown,
paul.gortmaker, dhowells, fenghua.yu, borislav.petkov, yinghai,
cpw, steiner, linux-kernel, yongjie.ren
On Sat, Apr 28, 2012 at 04:51:38PM +0800, Alex Shi wrote:
> 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 * 100ns(assumed TLB refill cost) =
> x(TLB flush entries) * 140ns(assumed invlpg cost)
>
> Here, x is about 360, that is about 5/8 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.
You could find the proper value empirically here by replacing the
FLUSHALL_BAR thing with a variable and exporting it through procfs or
sysfs or whatever, only for testing purposes, and letting mprotect.c
set it to a different value each time. Then run a bunch of times with
different thread counts and invalidation entries count and see which
combination performs best.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-04-30 10:54 ` Borislav Petkov
@ 2012-05-02 9:24 ` Alex Shi
2012-05-02 9:38 ` Borislav Petkov
0 siblings, 1 reply; 17+ messages in thread
From: Alex Shi @ 2012-05-02 9:24 UTC (permalink / raw)
To: Borislav Petkov
Cc: andi.kleen, tim.c.chen, jeremy, chrisw, akataria, tglx, mingo,
hpa, rostedt, fweisbec, riel, luto, avi, len.brown,
paul.gortmaker, dhowells, fenghua.yu, borislav.petkov, yinghai,
cpw, steiner, linux-kernel, yongjie.ren
On 04/30/2012 06:54 PM, Borislav Petkov wrote:
> On Sat, Apr 28, 2012 at 04:51:38PM +0800, Alex Shi wrote:
>> 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 * 100ns(assumed TLB refill cost) =
>> x(TLB flush entries) * 140ns(assumed invlpg cost)
>>
>> Here, x is about 360, that is about 5/8 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.
>
> You could find the proper value empirically here by replacing the
> FLUSHALL_BAR thing with a variable and exporting it through procfs or
> sysfs or whatever, only for testing purposes, and letting mprotect.c
> set it to a different value each time. Then run a bunch of times with
> different thread counts and invalidation entries count and see which
> combination performs best.
For some of scenario, above equation can be modified as:
(512 - X) * 100ns(assumed TLB refill cost) = X * 140ns(assumed invlpg cost)
When thread number less than cpu numbers, balance point can up to 1/2
TLB entries.
When thread number is equal to cpu number with HT, on our SNB EP
machine, the balance point is 1/16 TLB entries, on NHM EP machine,
balance at 1/32. So, need to change FLUSHALL_BAR to 32.
when thread number is bigger than cpu number, context switch eat all
improvement. the memory access latency is same as unpatched kernel.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-05-02 9:24 ` Alex Shi
@ 2012-05-02 9:38 ` Borislav Petkov
2012-05-02 11:38 ` Alex Shi
0 siblings, 1 reply; 17+ messages in thread
From: Borislav Petkov @ 2012-05-02 9:38 UTC (permalink / raw)
To: Alex Shi
Cc: Borislav Petkov, andi.kleen, tim.c.chen, jeremy, chrisw, akataria,
tglx, mingo, hpa, rostedt, fweisbec, riel, luto, avi, len.brown,
paul.gortmaker, dhowells, fenghua.yu, yinghai, cpw, steiner,
linux-kernel, yongjie.ren
On Wed, May 02, 2012 at 05:24:09PM +0800, Alex Shi wrote:
> For some of scenario, above equation can be modified as:
> (512 - X) * 100ns(assumed TLB refill cost) = X * 140ns(assumed invlpg cost)
>
> When thread number less than cpu numbers, balance point can up to 1/2
> TLB entries.
>
> When thread number is equal to cpu number with HT, on our SNB EP
> machine, the balance point is 1/16 TLB entries, on NHM EP machine,
> balance at 1/32. So, need to change FLUSHALL_BAR to 32.
Are you saying you want to have this setting per family?
Also, have you run your patches with other benchmarks beside your
microbenchmark, say kernbench, SPEC<something>, i.e. some other
multithreaded benchmark touching shared memory? Are you seeing any
improvement there?
> when thread number is bigger than cpu number, context switch eat all
> improvement. the memory access latency is same as unpatched kernel.
Also, how do you know in the kernel that the thread number is the number
of all threads touching this shared mmapped region - there could be
unrelated threads doing something else.
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-05-02 9:38 ` Borislav Petkov
@ 2012-05-02 11:38 ` Alex Shi
2012-05-02 13:04 ` Nick Piggin
2012-05-02 13:44 ` Borislav Petkov
0 siblings, 2 replies; 17+ messages in thread
From: Alex Shi @ 2012-05-02 11:38 UTC (permalink / raw)
To: Borislav Petkov
Cc: andi.kleen, tim.c.chen, jeremy, chrisw, akataria, tglx, mingo,
hpa, rostedt, fweisbec, riel, luto, avi, len.brown,
paul.gortmaker, dhowells, fenghua.yu, yinghai, cpw, steiner,
linux-kernel, yongjie.ren
On 05/02/2012 05:38 PM, Borislav Petkov wrote:
> On Wed, May 02, 2012 at 05:24:09PM +0800, Alex Shi wrote:
>> For some of scenario, above equation can be modified as:
>> (512 - X) * 100ns(assumed TLB refill cost) = X * 140ns(assumed invlpg cost)
>>
>> When thread number less than cpu numbers, balance point can up to 1/2
>> TLB entries.
>>
>> When thread number is equal to cpu number with HT, on our SNB EP
>> machine, the balance point is 1/16 TLB entries, on NHM EP machine,
>> balance at 1/32. So, need to change FLUSHALL_BAR to 32.
>
> Are you saying you want to have this setting per family?
Set it according to CPU type is more precise, but looks ugly. I am
wondering if it worth to do. Maybe conservative selection is acceptable?
>
> Also, have you run your patches with other benchmarks beside your
> microbenchmark, say kernbench, SPEC<something>, i.e. some other
> multithreaded benchmark touching shared memory? Are you seeing any
> improvement there?
I tested oltp reading and specjbb2005 with openjdk. They should not much
flush_tlb_range calling. So, no clear improvement.
Do you know benchmarks which cause enough flush_tlb_range?
>
>> when thread number is bigger than cpu number, context switch eat all
>> improvement. the memory access latency is same as unpatched kernel.
>
> Also, how do you know in the kernel that the thread number is the number
> of all threads touching this shared mmapped region - there could be
> unrelated threads doing something else.
Believe we didn't need to know this, much more thread number just weaken
and cover the improvement. When the thread number goes down, the
performance gain appears. So, don't need care this.
Any more comments for this patchset?
>
> Thanks.
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-05-02 11:38 ` Alex Shi
@ 2012-05-02 13:04 ` Nick Piggin
2012-05-02 13:15 ` Alex Shi
` (2 more replies)
2012-05-02 13:44 ` Borislav Petkov
1 sibling, 3 replies; 17+ messages in thread
From: Nick Piggin @ 2012-05-02 13:04 UTC (permalink / raw)
To: Alex Shi
Cc: Borislav Petkov, andi.kleen, tim.c.chen, jeremy, chrisw, akataria,
tglx, mingo, hpa, rostedt, fweisbec, riel, luto, avi, len.brown,
paul.gortmaker, dhowells, fenghua.yu, yinghai, cpw, steiner,
linux-kernel, yongjie.ren
On 2 May 2012 21:38, Alex Shi <alex.shi@intel.com> wrote:
> On 05/02/2012 05:38 PM, Borislav Petkov wrote:
>
>> On Wed, May 02, 2012 at 05:24:09PM +0800, Alex Shi wrote:
>>> For some of scenario, above equation can be modified as:
>>> (512 - X) * 100ns(assumed TLB refill cost) = X * 140ns(assumed invlpg cost)
It should not be that optimistic, because that equation assumes every
unflushed entry saves a TLB refill too.
I think it is always a good idea to make such fundamental primitives
cheaper though.
>> Also, have you run your patches with other benchmarks beside your
>> microbenchmark, say kernbench, SPEC<something>, i.e. some other
>> multithreaded benchmark touching shared memory? Are you seeing any
>> improvement there?
>
>
> I tested oltp reading and specjbb2005 with openjdk. They should not much
> flush_tlb_range calling. So, no clear improvement.
> Do you know benchmarks which cause enough flush_tlb_range?
x86 does not do such invlpg flushing for munmap either, as far as I
can see?
It would be a little more work to make this happen, but it might show
more benefit, provided glibc does not free too huge chunks at once,
it should apply far more often.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-05-02 13:04 ` Nick Piggin
@ 2012-05-02 13:15 ` Alex Shi
2012-05-02 13:24 ` Alex Shi
2012-05-06 2:55 ` Alex Shi
2 siblings, 0 replies; 17+ messages in thread
From: Alex Shi @ 2012-05-02 13:15 UTC (permalink / raw)
To: Nick Piggin
Cc: Borislav Petkov, andi.kleen, tim.c.chen, jeremy, chrisw, akataria,
tglx, mingo, hpa, rostedt, fweisbec, riel, luto, avi, len.brown,
paul.gortmaker, dhowells, fenghua.yu, yinghai, cpw, steiner,
linux-kernel, yongjie.ren
On 05/02/2012 09:04 PM, Nick Piggin wrote:
> On 2 May 2012 21:38, Alex Shi <alex.shi@intel.com> wrote:
>> On 05/02/2012 05:38 PM, Borislav Petkov wrote:
>>
>>> On Wed, May 02, 2012 at 05:24:09PM +0800, Alex Shi wrote:
>>>> For some of scenario, above equation can be modified as:
>>>> (512 - X) * 100ns(assumed TLB refill cost) = X * 140ns(assumed invlpg cost)
>
> It should not be that optimistic, because that equation assumes every
> unflushed entry saves a TLB refill too.
>
> I think it is always a good idea to make such fundamental primitives
> cheaper though.
>
>
>>> Also, have you run your patches with other benchmarks beside your
>>> microbenchmark, say kernbench, SPEC<something>, i.e. some other
>>> multithreaded benchmark touching shared memory? Are you seeing any
>>> improvement there?
>>
>>
>> I tested oltp reading and specjbb2005 with openjdk. They should not much
>> flush_tlb_range calling. So, no clear improvement.
>> Do you know benchmarks which cause enough flush_tlb_range?
>
> x86 does not do such invlpg flushing for munmap either, as far as I
> can see?
>
> It would be a little more work to make this happen, but it might show
> more benefit, provided glibc does not free too huge chunks at once,
> it should apply far more often.
Good idea, and it is worthy to try!
But anyway, it is another job. :)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-05-02 13:04 ` Nick Piggin
2012-05-02 13:15 ` Alex Shi
@ 2012-05-02 13:24 ` Alex Shi
2012-05-06 2:55 ` Alex Shi
2 siblings, 0 replies; 17+ messages in thread
From: Alex Shi @ 2012-05-02 13:24 UTC (permalink / raw)
To: Nick Piggin
Cc: Borislav Petkov, andi.kleen, tim.c.chen, jeremy, chrisw, akataria,
tglx, mingo, hpa, rostedt, fweisbec, riel, luto, avi, len.brown,
paul.gortmaker, dhowells, fenghua.yu, yinghai, cpw, steiner,
linux-kernel, yongjie.ren
On 05/02/2012 09:04 PM, Nick Piggin wrote:
> On 2 May 2012 21:38, Alex Shi <alex.shi@intel.com> wrote:
>> On 05/02/2012 05:38 PM, Borislav Petkov wrote:
>>
>>> On Wed, May 02, 2012 at 05:24:09PM +0800, Alex Shi wrote:
>>>> For some of scenario, above equation can be modified as:
>>>> (512 - X) * 100ns(assumed TLB refill cost) = X * 140ns(assumed invlpg cost)
>
> It should not be that optimistic, because that equation assumes every
> unflushed entry saves a TLB refill too.
>
Yes, it is just ideal scenario to do analysis. In the code, the judgment
depends on the 'active entries' instead of the fixed TLB line number.
active entries = min(this process's page number, TLB line number)
> I think it is always a good idea to make such fundamental primitives
> cheaper though.
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-05-02 11:38 ` Alex Shi
2012-05-02 13:04 ` Nick Piggin
@ 2012-05-02 13:44 ` Borislav Petkov
2012-05-03 9:15 ` Alex Shi
1 sibling, 1 reply; 17+ messages in thread
From: Borislav Petkov @ 2012-05-02 13:44 UTC (permalink / raw)
To: Alex Shi
Cc: Borislav Petkov, andi.kleen, tim.c.chen, jeremy, chrisw, akataria,
tglx, mingo, hpa, rostedt, fweisbec, riel, luto, avi, len.brown,
paul.gortmaker, dhowells, fenghua.yu, yinghai, cpw, steiner,
linux-kernel, yongjie.ren
On Wed, May 02, 2012 at 07:38:47PM +0800, Alex Shi wrote:
> > Are you saying you want to have this setting per family?
>
> Set it according to CPU type is more precise, but looks ugly.
By "CPU type" do you mean microarchitecture here?
> I am wondering if it worth to do. Maybe conservative selection is
> acceptable?
Well, as I said earlier, I'd run it on a couple of different machines
and make FLUSHALL_BAR configurable from userspace - this way you have
real, solid data instead of guessing the exact number.
> > Also, have you run your patches with other benchmarks beside your
> > microbenchmark, say kernbench, SPEC<something>, i.e. some other
> > multithreaded benchmark touching shared memory? Are you seeing any
> > improvement there?
>
> I tested oltp reading and specjbb2005 with openjdk. They should not much
> flush_tlb_range calling. So, no clear improvement.
> Do you know benchmarks which cause enough flush_tlb_range?
Not really. Probably get a couple of benchmarks and count
flush_tlb_range calls with trace_printk or perf probe? :-)
[..]
> Believe we didn't need to know this, much more thread number just
> weaken and cover the improvement. When the thread number goes down,
> the performance gain appears. So, don't need care this.
Ok, this is also what the data showed, much higher gain with smaller
thread counts.
> Any more comments for this patchset?
Nope, thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/3] x86/tlb_info: get last level TLB entry number of CPU
2012-04-28 8:50 [PATCH 1/3] x86/tlb_info: get last level TLB entry number of CPU Alex Shi
2012-04-28 8:50 ` [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range Alex Shi
@ 2012-05-02 15:13 ` Rik van Riel
1 sibling, 0 replies; 17+ messages in thread
From: Rik van Riel @ 2012-05-02 15:13 UTC (permalink / raw)
To: Alex Shi
Cc: andi.kleen, tim.c.chen, jeremy, chrisw, akataria, tglx, mingo,
hpa, rostedt, fweisbec, luto, avi, len.brown, paul.gortmaker,
dhowells, fenghua.yu, borislav.petkov, yinghai, cpw, steiner,
linux-kernel
On 04/28/2012 04:50 AM, Alex Shi wrote:
> For 4KB pages, x86 CPU has 2 or 1 level TLB, first level is data TLB and
> instruction TLB, second level is shared TLB for both data and instructions.
>
> For hupe page TLB, usually there is just one level and seperated by 2MB/4MB
> and 1GB.
>
> Although each levels TLB size is important for performance tuning, but for
> genernal and rude optimizing, just last level TLB entry number is suitable.
> And in fact, last level TLB has the biggest entry number.
>
> This patch will get the biggest TLB entry number and use it in furture TLB
> optimizing.
>
> Signed-off-by: Alex Shi<alex.shi@intel.com>
Acked-by: Rik van Riel <riel@redhat.com>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-04-28 8:50 ` [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range Alex Shi
@ 2012-05-02 15:21 ` Rik van Riel
0 siblings, 0 replies; 17+ messages in thread
From: Rik van Riel @ 2012-05-02 15:21 UTC (permalink / raw)
To: Alex Shi
Cc: andi.kleen, tim.c.chen, jeremy, chrisw, akataria, tglx, mingo,
hpa, rostedt, fweisbec, luto, avi, len.brown, paul.gortmaker,
dhowells, fenghua.yu, borislav.petkov, yinghai, cpw, steiner,
linux-kernel
On 04/28/2012 04:50 AM, Alex Shi wrote:
> 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 * 100ns(assumed TLB refill cost) =
> x(TLB flush entries) * 140ns(assumed invlpg cost)
>
> Here, x is about 360, that is about 5/8 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.
The numbers speak for themselves, 1/16th seems to work
fine on current generation CPUs.
> +
> +#define FLUSHALL_BAR 16
However, since this is a somewhat arbitrary number, it
would be good to accompany this #define with a multi-line
comment explaining your reasoning for choosing this number.
That will make it easy to re-evaluate in the future, if neeeded.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-05-02 13:44 ` Borislav Petkov
@ 2012-05-03 9:15 ` Alex Shi
0 siblings, 0 replies; 17+ messages in thread
From: Alex Shi @ 2012-05-03 9:15 UTC (permalink / raw)
To: Borislav Petkov
Cc: andi.kleen, tim.c.chen, jeremy, chrisw, akataria, tglx, mingo,
hpa, rostedt, fweisbec, riel, luto, avi, len.brown,
paul.gortmaker, dhowells, fenghua.yu, yinghai, cpw, steiner,
linux-kernel, yongjie.ren
On 05/02/2012 09:44 PM, Borislav Petkov wrote:
> On Wed, May 02, 2012 at 07:38:47PM +0800, Alex Shi wrote:
>>> Are you saying you want to have this setting per family?
>>
>> Set it according to CPU type is more precise, but looks ugly.
>
> By "CPU type" do you mean microarchitecture here?
Yes.
>
>> I am wondering if it worth to do. Maybe conservative selection is
>> acceptable?
>
> Well, as I said earlier, I'd run it on a couple of different machines
> and make FLUSHALL_BAR configurable from userspace - this way you have
> real, solid data instead of guessing the exact number.
Consider different CPU type has different balance point, I has another
patch will add a interface for tuning.
>
>>> Also, have you run your patches with other benchmarks beside your
>>> microbenchmark, say kernbench, SPEC<something>, i.e. some other
>>> multithreaded benchmark touching shared memory? Are you seeing any
>>> improvement there?
>>
>> I tested oltp reading and specjbb2005 with openjdk. They should not much
>> flush_tlb_range calling. So, no clear improvement.
>> Do you know benchmarks which cause enough flush_tlb_range?
>
> Not really. Probably get a couple of benchmarks and count
> flush_tlb_range calls with trace_printk or perf probe? :-)
perf probe is enough. :)
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-04-28 8:51 ` [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range Alex Shi
2012-04-30 10:54 ` Borislav Petkov
@ 2012-05-04 2:24 ` Ren, Yongjie
2012-05-04 5:46 ` Alex Shi
1 sibling, 1 reply; 17+ messages in thread
From: Ren, Yongjie @ 2012-05-04 2:24 UTC (permalink / raw)
To: Shi, Alex, Kleen, Andi, tim.c.chen@linux.intel.com,
jeremy@goop.org, chrisw@sous-sol.org, akataria@vmware.com,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
rostedt@goodmis.org, fweisbec@gmail.com
Cc: riel@redhat.com, luto@mit.edu, avi@redhat.com, Brown, Len,
paul.gortmaker@windriver.com, dhowells@redhat.com, Yu, Fenghua,
borislav.petkov@amd.com, yinghai@kernel.org, cpw@sgi.com,
steiner@sgi.com, linux-kernel@vger.kernel.org
> Signed-off-by: Alex Shi <alex.shi@intel.com>
> ---
> arch/x86/include/asm/paravirt.h | 5 +-
> arch/x86/include/asm/paravirt_types.h | 3 +-
> arch/x86/include/asm/tlbflush.h | 19 +++----
> arch/x86/include/asm/uv/uv.h | 5 +-
> arch/x86/mm/tlb.c | 97
> +++++++++++++++++++++++++++------
> arch/x86/platform/uv/tlb_uv.c | 6 +-
> arch/x86/xen/mmu.c | 9 ++--
> include/trace/events/xen.h | 12 +++--
> 8 files changed, 113 insertions(+), 43 deletions(-)
As the patch series touched some Xen virtualization code, I just did some simple test on Xen and KVM.
It seems these patches work fine on Xen/KVM virtual side.
I started an SMP PV guest and an SMP HVM guest on Xen, and an SMP guest on KVM.
Best Regards,
Yongjie (Jay)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-05-04 2:24 ` Ren, Yongjie
@ 2012-05-04 5:46 ` Alex Shi
0 siblings, 0 replies; 17+ messages in thread
From: Alex Shi @ 2012-05-04 5:46 UTC (permalink / raw)
To: Ren, Yongjie
Cc: Kleen, Andi, tim.c.chen@linux.intel.com, jeremy@goop.org,
chrisw@sous-sol.org, akataria@vmware.com, tglx@linutronix.de,
mingo@redhat.com, hpa@zytor.com, rostedt@goodmis.org,
fweisbec@gmail.com, riel@redhat.com, luto@mit.edu, avi@redhat.com,
Brown, Len, paul.gortmaker@windriver.com, dhowells@redhat.com,
Yu, Fenghua, borislav.petkov@amd.com, yinghai@kernel.org,
cpw@sgi.com, steiner@sgi.com, linux-kernel@vger.kernel.org
On 05/04/2012 10:24 AM, Ren, Yongjie wrote:
>> Signed-off-by: Alex Shi <alex.shi@intel.com>
>> ---
>> arch/x86/include/asm/paravirt.h | 5 +-
>> arch/x86/include/asm/paravirt_types.h | 3 +-
>> arch/x86/include/asm/tlbflush.h | 19 +++----
>> arch/x86/include/asm/uv/uv.h | 5 +-
>> arch/x86/mm/tlb.c | 97
>> +++++++++++++++++++++++++++------
>> arch/x86/platform/uv/tlb_uv.c | 6 +-
>> arch/x86/xen/mmu.c | 9 ++--
>> include/trace/events/xen.h | 12 +++--
>> 8 files changed, 113 insertions(+), 43 deletions(-)
>
> As the patch series touched some Xen virtualization code, I just did some simple test on Xen and KVM.
> It seems these patches work fine on Xen/KVM virtual side.
> I started an SMP PV guest and an SMP HVM guest on Xen, and an SMP guest on KVM.
>
> Best Regards,
> Yongjie (Jay)
>
Thanks a lot! Yongjie.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
2012-05-02 13:04 ` Nick Piggin
2012-05-02 13:15 ` Alex Shi
2012-05-02 13:24 ` Alex Shi
@ 2012-05-06 2:55 ` Alex Shi
2 siblings, 0 replies; 17+ messages in thread
From: Alex Shi @ 2012-05-06 2:55 UTC (permalink / raw)
To: Nick Piggin, mgorman
Cc: Borislav Petkov, andi.kleen, tim.c.chen, jeremy, chrisw, akataria,
tglx, mingo, hpa, rostedt, fweisbec, riel, luto, avi, len.brown,
paul.gortmaker, dhowells, fenghua.yu, yinghai, cpw, steiner,
linux-kernel, yongjie.ren
>>
>> I tested oltp reading and specjbb2005 with openjdk. They should not much
>> flush_tlb_range calling. So, no clear improvement.
>> Do you know benchmarks which cause enough flush_tlb_range?
>
> x86 does not do such invlpg flushing for munmap either, as far as I
> can see?
>
> It would be a little more work to make this happen, but it might show
> more benefit, provided glibc does not free too huge chunks at once,
> it should apply far more often.
I enabled invlpg for munmap and zap_page_range base on v2 of this patchset.
but still haven't find clear performance increase for benchmarks:
specjbb2005/kbuild/hackbench/netperf-loop/oltp/fileio etc. with THP always.
Does anyone know some benchmark has much munmap?
---------
>From 7a4bbd1a5fdde396556fd40d9899e737d71f5a3c Mon Sep 17 00:00:00 2001
From: Alex Shi <alex.shi@intel.com>
Date: Sat, 5 May 2012 12:04:00 +0800
Subject: [PATCH 6/6] x86/tlb: optimizing munmap.
a rough patch of changing flush_tlb_mm(mm), to flush_tlb_mm(mm, start, end)
---
arch/x86/include/asm/tlb.h | 2 +-
arch/x86/include/asm/tlbflush.h | 5 ++-
arch/x86/mm/pgtable.c | 2 +-
arch/x86/mm/tlb.c | 74 +++++++++++++++++---------------------
fs/proc/task_mmu.c | 2 +-
include/asm-generic/tlb.h | 4 +-
include/asm-generic/tlbflush.h | 3 +-
kernel/fork.c | 2 +-
mm/memory.c | 11 ++++--
9 files changed, 51 insertions(+), 54 deletions(-)
diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h
index 829215f..505fdfe 100644
--- a/arch/x86/include/asm/tlb.h
+++ b/arch/x86/include/asm/tlb.h
@@ -4,7 +4,7 @@
#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) flush_tlb_mm((tlb)->mm)
+#define tlb_flush(tlb, start, end) flush_tlb_mm((tlb)->mm, start, end)
#include <asm-generic/tlb.h>
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 51f8b1c..d1baeac 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -89,7 +89,8 @@ static inline void __flush_tlb_one(unsigned long addr)
#define flush_tlb_all() __flush_tlb_all()
#define local_flush_tlb() __flush_tlb()
-static inline void flush_tlb_mm(struct mm_struct *mm)
+static inline void flush_tlb_mm(struct mm_struct *mm,
+ unsigned long start, unsigned long end)
{
if (mm == current->active_mm)
__flush_tlb();
@@ -128,7 +129,7 @@ static inline void reset_lazy_tlbstate(void)
extern void flush_tlb_all(void);
extern void flush_tlb_current_task(void);
-extern void flush_tlb_mm(struct mm_struct *);
+extern void flush_tlb_mm(struct mm_struct *, unsigned long, unsigned long);
extern void flush_tlb_page(struct vm_area_struct *, unsigned long);
extern void flush_tlb_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end);
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 8573b83..204221c 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -168,7 +168,7 @@ void pud_populate(struct mm_struct *mm, pud_t *pudp, pmd_t *pmd)
* section 8.1: in PAE mode we explicitly have to flush the
* TLB via cr3 if the top-level pgd is changed...
*/
- flush_tlb_mm(mm);
+ flush_tlb_mm(mm, 0, -1);
}
#else /* !CONFIG_X86_PAE */
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 91896dc..5f9a327 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -298,22 +298,6 @@ void flush_tlb_current_task(void)
preempt_enable();
}
-void flush_tlb_mm(struct mm_struct *mm)
-{
- preempt_disable();
-
- if (current->active_mm == mm) {
- if (current->mm)
- local_flush_tlb();
- else
- leave_mm(smp_processor_id());
- }
- if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
- flush_tlb_others(mm_cpumask(mm), mm, TLB_FLUSH_ALL, 0UL);
-
- preempt_enable();
-}
-
static inline int has_large_page(struct mm_struct *mm,
unsigned long start, unsigned long end)
{
@@ -336,39 +320,27 @@ static inline int has_large_page(struct mm_struct *mm,
return 0;
}
-void flush_tlb_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end)
+void __flush_tlb_range(struct mm_struct *mm, unsigned long start,
+ unsigned long end, unsigned long vmflag)
{
- struct mm_struct *mm;
-
- if (!cpu_has_invlpg || vma->vm_flags & VM_HUGETLB
- || !tlb_flushall_factor) {
-flush_all:
- flush_tlb_mm(vma->vm_mm);
- return;
- }
-
preempt_disable();
- mm = vma->vm_mm;
if (current->active_mm == mm) {
if (current->mm) {
- unsigned long addr, vmflag = vma->vm_flags;
- unsigned act_entries, tlb_entries = 0;
-
- if (vmflag & VM_EXEC)
- tlb_entries = tlb_lli_4k[ENTRIES];
- else
- tlb_entries = tlb_lld_4k[ENTRIES];
-
- act_entries = tlb_entries > mm->total_vm ?
- mm->total_vm : tlb_entries;
-
- if ((end - start)/PAGE_SIZE >
+ if ( start == 0 || (end - start)/PAGE_SIZE >
act_entries/tlb_flushall_factor)
local_flush_tlb();
else {
+ unsigned long addr;
+ unsigned long act_entries, tlb_entries = 0;
+
+ if (vmflag & VM_EXEC)
+ tlb_entries = tlb_lli_4k[ENTRIES];
+ else
+ tlb_entries = tlb_lld_4k[ENTRIES];
+ act_entries = min(mm->total_vm, tlb_entries);
+
if (has_large_page(mm, start, end)) {
- preempt_enable();
+ local_flush_tlb();
goto flush_all;
}
for (addr = start; addr <= end;
@@ -386,11 +358,31 @@ flush_all:
leave_mm(smp_processor_id());
}
}
+
+flush_all:
if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
flush_tlb_others(mm_cpumask(mm), mm, TLB_FLUSH_ALL, 0UL);
preempt_enable();
}
+void flush_tlb_mm(struct mm_struct *mm, unsigned long start, unsigned long end)
+{
+ __flush_tlb_range(mm, start, end, 0UL);
+}
+
+void flush_tlb_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+ struct mm_struct *mm = vma->vm_mm;
+ unsigned long vmflag = vma->vm_flags;
+
+ if (!cpu_has_invlpg || vma->vm_flags & VM_HUGETLB
+ || !tlb_flushall_factor)
+ __flush_tlb_range(mm, 0UL, -1UL, 0);
+ else
+ __flush_tlb_range(mm, start, end, vmflag);
+}
+
void flush_tlb_page(struct vm_area_struct *vma, unsigned long start)
{
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 2d60492..b2c9659 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -660,7 +660,7 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf,
walk_page_range(vma->vm_start, vma->vm_end,
&clear_refs_walk);
}
- flush_tlb_mm(mm);
+ flush_tlb_mm(mm, 0, -1);
up_read(&mm->mmap_sem);
mmput(mm);
}
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index f96a5b5..24e205d 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -112,7 +112,7 @@ static inline int tlb_fast_mode(struct mmu_gather *tlb)
}
void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, bool fullmm);
-void tlb_flush_mmu(struct mmu_gather *tlb);
+void tlb_flush_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end);
void tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end);
int __tlb_remove_page(struct mmu_gather *tlb, struct page *page);
@@ -123,7 +123,7 @@ int __tlb_remove_page(struct mmu_gather *tlb, struct page *page);
static inline void tlb_remove_page(struct mmu_gather *tlb, struct page *page)
{
if (!__tlb_remove_page(tlb, page))
- tlb_flush_mmu(tlb);
+ tlb_flush_mmu(tlb, 0UL, -1UL);
}
/**
diff --git a/include/asm-generic/tlbflush.h b/include/asm-generic/tlbflush.h
index d6d0a88..db1d4bb 100644
--- a/include/asm-generic/tlbflush.h
+++ b/include/asm-generic/tlbflush.h
@@ -11,7 +11,8 @@
#include <linux/bug.h>
-static inline void flush_tlb_mm(struct mm_struct *mm)
+static inline void flush_tlb_mm(struct mm_struct *mm,
+ unsigned long start, unsigned long end)
{
BUG();
}
diff --git a/kernel/fork.c b/kernel/fork.c
index b9372a0..0e895e8 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -427,7 +427,7 @@ static int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm)
retval = 0;
out:
up_write(&mm->mmap_sem);
- flush_tlb_mm(oldmm);
+ flush_tlb_mm(oldmm, 0, -1);
up_write(&oldmm->mmap_sem);
return retval;
fail_nomem_anon_vma_fork:
diff --git a/mm/memory.c b/mm/memory.c
index 6105f47..c25c9ea 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -218,14 +218,15 @@ void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, bool fullmm)
#endif
}
-void tlb_flush_mmu(struct mmu_gather *tlb)
+void tlb_flush_mmu(struct mmu_gather *tlb,
+ unsigned long start, unsigned long end)
{
struct mmu_gather_batch *batch;
if (!tlb->need_flush)
return;
tlb->need_flush = 0;
- tlb_flush(tlb);
+ tlb_flush(tlb, start, end);
#ifdef CONFIG_HAVE_RCU_TABLE_FREE
tlb_table_flush(tlb);
#endif
@@ -248,7 +249,7 @@ void tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long e
{
struct mmu_gather_batch *batch, *next;
- tlb_flush_mmu(tlb);
+ tlb_flush_mmu(tlb, start, end);
/* keep the page table cache within bounds */
check_pgt_cache();
@@ -396,6 +397,8 @@ void pmd_clear_bad(pmd_t *pmd)
* Note: this doesn't free the actual pages themselves. That
* has been handled earlier when unmapping all the memory regions.
*/
+// pte_free_tlb -> tlb_remove_page -> tlb_flush_mmu
+// that may cause too much tlb flushing. alex
static void free_pte_range(struct mmu_gather *tlb, pmd_t *pmd,
unsigned long addr)
{
@@ -1204,7 +1207,7 @@ again:
*/
if (force_flush) {
force_flush = 0;
- tlb_flush_mmu(tlb);
+ tlb_flush_mmu(tlb, addr, end);
if (addr != end)
goto again;
}
--
1.7.5.4
^ permalink raw reply related [flat|nested] 17+ messages in thread
end of thread, other threads:[~2012-05-06 2:56 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-28 8:50 [PATCH 1/3] x86/tlb_info: get last level TLB entry number of CPU Alex Shi
2012-04-28 8:50 ` [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range Alex Shi
2012-05-02 15:21 ` Rik van Riel
2012-05-02 15:13 ` [PATCH 1/3] x86/tlb_info: get last level TLB entry number of CPU Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2012-04-28 8:51 [PATCH 0/3] TLB flush range optimization Alex Shi
2012-04-28 8:51 ` [PATCH 2/3] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range Alex Shi
2012-04-30 10:54 ` Borislav Petkov
2012-05-02 9:24 ` Alex Shi
2012-05-02 9:38 ` Borislav Petkov
2012-05-02 11:38 ` Alex Shi
2012-05-02 13:04 ` Nick Piggin
2012-05-02 13:15 ` Alex Shi
2012-05-02 13:24 ` Alex Shi
2012-05-06 2:55 ` Alex Shi
2012-05-02 13:44 ` Borislav Petkov
2012-05-03 9:15 ` Alex Shi
2012-05-04 2:24 ` Ren, Yongjie
2012-05-04 5:46 ` Alex Shi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox