2008-10-23 12:26:29 +07:00
|
|
|
#ifndef _ASM_X86_TLBFLUSH_H
|
|
|
|
#define _ASM_X86_TLBFLUSH_H
|
2008-01-30 19:30:35 +07:00
|
|
|
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
|
|
|
|
#include <asm/processor.h>
|
2016-01-27 04:12:04 +07:00
|
|
|
#include <asm/cpufeature.h>
|
2012-03-29 00:11:12 +07:00
|
|
|
#include <asm/special_insns.h>
|
2017-05-29 00:00:14 +07:00
|
|
|
#include <asm/smp.h>
|
2008-01-30 19:30:35 +07:00
|
|
|
|
2016-01-30 02:42:57 +07:00
|
|
|
static inline void __invpcid(unsigned long pcid, unsigned long addr,
|
|
|
|
unsigned long type)
|
|
|
|
{
|
2016-02-10 21:51:16 +07:00
|
|
|
struct { u64 d[2]; } desc = { { pcid, addr } };
|
2016-01-30 02:42:57 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The memory clobber is because the whole point is to invalidate
|
|
|
|
* stale TLB entries and, especially if we're flushing global
|
|
|
|
* mappings, we don't want the compiler to reorder any subsequent
|
|
|
|
* memory accesses before the TLB flush.
|
|
|
|
*
|
|
|
|
* The hex opcode is invpcid (%ecx), %eax in 32-bit mode and
|
|
|
|
* invpcid (%rcx), %rax in long mode.
|
|
|
|
*/
|
|
|
|
asm volatile (".byte 0x66, 0x0f, 0x38, 0x82, 0x01"
|
2016-02-10 21:51:16 +07:00
|
|
|
: : "m" (desc), "a" (type), "c" (&desc) : "memory");
|
2016-01-30 02:42:57 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
#define INVPCID_TYPE_INDIV_ADDR 0
|
|
|
|
#define INVPCID_TYPE_SINGLE_CTXT 1
|
|
|
|
#define INVPCID_TYPE_ALL_INCL_GLOBAL 2
|
|
|
|
#define INVPCID_TYPE_ALL_NON_GLOBAL 3
|
|
|
|
|
|
|
|
/* Flush all mappings for a given pcid and addr, not including globals. */
|
|
|
|
static inline void invpcid_flush_one(unsigned long pcid,
|
|
|
|
unsigned long addr)
|
|
|
|
{
|
|
|
|
__invpcid(pcid, addr, INVPCID_TYPE_INDIV_ADDR);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Flush all mappings for a given PCID, not including globals. */
|
|
|
|
static inline void invpcid_flush_single_context(unsigned long pcid)
|
|
|
|
{
|
|
|
|
__invpcid(pcid, 0, INVPCID_TYPE_SINGLE_CTXT);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Flush all mappings, including globals, for all PCIDs. */
|
|
|
|
static inline void invpcid_flush_all(void)
|
|
|
|
{
|
|
|
|
__invpcid(0, 0, INVPCID_TYPE_ALL_INCL_GLOBAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Flush all mappings for all PCIDs except globals. */
|
|
|
|
static inline void invpcid_flush_all_nonglobals(void)
|
|
|
|
{
|
|
|
|
__invpcid(0, 0, INVPCID_TYPE_ALL_NON_GLOBAL);
|
|
|
|
}
|
|
|
|
|
2017-06-29 22:53:15 +07:00
|
|
|
static inline u64 inc_mm_tlb_gen(struct mm_struct *mm)
|
|
|
|
{
|
|
|
|
u64 new_tlb_gen;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Bump the generation count. This also serves as a full barrier
|
|
|
|
* that synchronizes with switch_mm(): callers are required to order
|
|
|
|
* their read of mm_cpumask after their writes to the paging
|
|
|
|
* structures.
|
|
|
|
*/
|
|
|
|
smp_mb__before_atomic();
|
|
|
|
new_tlb_gen = atomic64_inc_return(&mm->context.tlb_gen);
|
|
|
|
smp_mb__after_atomic();
|
|
|
|
|
|
|
|
return new_tlb_gen;
|
|
|
|
}
|
|
|
|
|
2008-01-30 19:30:35 +07:00
|
|
|
#ifdef CONFIG_PARAVIRT
|
|
|
|
#include <asm/paravirt.h>
|
|
|
|
#else
|
|
|
|
#define __flush_tlb() __native_flush_tlb()
|
|
|
|
#define __flush_tlb_global() __native_flush_tlb_global()
|
|
|
|
#define __flush_tlb_single(addr) __native_flush_tlb_single(addr)
|
|
|
|
#endif
|
|
|
|
|
x86/mm: Implement PCID based optimization: try to preserve old TLB entries using PCID
PCID is a "process context ID" -- it's what other architectures call
an address space ID. Every non-global TLB entry is tagged with a
PCID, only TLB entries that match the currently selected PCID are
used, and we can switch PGDs without flushing the TLB. x86's
PCID is 12 bits.
This is an unorthodox approach to using PCID. x86's PCID is far too
short to uniquely identify a process, and we can't even really
uniquely identify a running process because there are monster
systems with over 4096 CPUs. To make matters worse, past attempts
to use all 12 PCID bits have resulted in slowdowns instead of
speedups.
This patch uses PCID differently. We use a PCID to identify a
recently-used mm on a per-cpu basis. An mm has no fixed PCID
binding at all; instead, we give it a fresh PCID each time it's
loaded except in cases where we want to preserve the TLB, in which
case we reuse a recent value.
Here are some benchmark results, done on a Skylake laptop at 2.3 GHz
(turbo off, intel_pstate requesting max performance) under KVM with
the guest using idle=poll (to avoid artifacts when bouncing between
CPUs). I haven't done any real statistics here -- I just ran them
in a loop and picked the fastest results that didn't look like
outliers. Unpatched means commit a4eb8b993554, so all the
bookkeeping overhead is gone.
ping-pong between two mms on the same CPU using eventfd:
patched: 1.22µs
patched, nopcid: 1.33µs
unpatched: 1.34µs
Same ping-pong, but now touch 512 pages (all zero-page to minimize
cache misses) each iteration. dTLB misses are measured by
dtlb_load_misses.miss_causes_a_walk:
patched: 1.8µs 11M dTLB misses
patched, nopcid: 6.2µs, 207M dTLB misses
unpatched: 6.1µs, 190M dTLB misses
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Nadav Amit <nadav.amit@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/9ee75f17a81770feed616358e6860d98a2a5b1e7.1500957502.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-25 11:41:38 +07:00
|
|
|
/*
|
|
|
|
* 6 because 6 should be plenty and struct tlb_state will fit in
|
|
|
|
* two cache lines.
|
|
|
|
*/
|
|
|
|
#define TLB_NR_DYN_ASIDS 6
|
|
|
|
|
2017-06-29 22:53:16 +07:00
|
|
|
struct tlb_context {
|
|
|
|
u64 ctx_id;
|
|
|
|
u64 tlb_gen;
|
|
|
|
};
|
|
|
|
|
2014-10-25 05:58:08 +07:00
|
|
|
struct tlb_state {
|
x86/mm: Rework lazy TLB to track the actual loaded mm
Lazy TLB state is currently managed in a rather baroque manner.
AFAICT, there are three possible states:
- Non-lazy. This means that we're running a user thread or a
kernel thread that has called use_mm(). current->mm ==
current->active_mm == cpu_tlbstate.active_mm and
cpu_tlbstate.state == TLBSTATE_OK.
- Lazy with user mm. We're running a kernel thread without an mm
and we're borrowing an mm_struct. We have current->mm == NULL,
current->active_mm == cpu_tlbstate.active_mm, cpu_tlbstate.state
!= TLBSTATE_OK (i.e. TLBSTATE_LAZY or 0). The current cpu is set
in mm_cpumask(current->active_mm). CR3 points to
current->active_mm->pgd. The TLB is up to date.
- Lazy with init_mm. This happens when we call leave_mm(). We
have current->mm == NULL, current->active_mm ==
cpu_tlbstate.active_mm, but that mm is only relelvant insofar as
the scheduler is tracking it for refcounting. cpu_tlbstate.state
!= TLBSTATE_OK. The current cpu is clear in
mm_cpumask(current->active_mm). CR3 points to swapper_pg_dir,
i.e. init_mm->pgd.
This patch simplifies the situation. Other than perf, x86 stops
caring about current->active_mm at all. We have
cpu_tlbstate.loaded_mm pointing to the mm that CR3 references. The
TLB is always up to date for that mm. leave_mm() just switches us
to init_mm. There are no longer any special cases for mm_cpumask,
and switch_mm() switches mms without worrying about laziness.
After this patch, cpu_tlbstate.state serves only to tell the TLB
flush code whether it may switch to init_mm instead of doing a
normal flush.
This makes fairly extensive changes to xen_exit_mmap(), which used
to look a bit like black magic.
Perf is unchanged. With or without this change, perf may behave a bit
erratically if it tries to read user memory in kernel thread context.
We should build on this patch to teach perf to never look at user
memory when cpu_tlbstate.loaded_mm != current->mm.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bpetkov@suse.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: Nadav Amit <namit@vmware.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-29 00:00:15 +07:00
|
|
|
/*
|
|
|
|
* cpu_tlbstate.loaded_mm should match CR3 whenever interrupts
|
|
|
|
* are on. This means that it may not match current->active_mm,
|
|
|
|
* which will contain the previous user mm when we're in lazy TLB
|
|
|
|
* mode even if we've already switched back to swapper_pg_dir.
|
|
|
|
*/
|
|
|
|
struct mm_struct *loaded_mm;
|
x86/mm: Implement PCID based optimization: try to preserve old TLB entries using PCID
PCID is a "process context ID" -- it's what other architectures call
an address space ID. Every non-global TLB entry is tagged with a
PCID, only TLB entries that match the currently selected PCID are
used, and we can switch PGDs without flushing the TLB. x86's
PCID is 12 bits.
This is an unorthodox approach to using PCID. x86's PCID is far too
short to uniquely identify a process, and we can't even really
uniquely identify a running process because there are monster
systems with over 4096 CPUs. To make matters worse, past attempts
to use all 12 PCID bits have resulted in slowdowns instead of
speedups.
This patch uses PCID differently. We use a PCID to identify a
recently-used mm on a per-cpu basis. An mm has no fixed PCID
binding at all; instead, we give it a fresh PCID each time it's
loaded except in cases where we want to preserve the TLB, in which
case we reuse a recent value.
Here are some benchmark results, done on a Skylake laptop at 2.3 GHz
(turbo off, intel_pstate requesting max performance) under KVM with
the guest using idle=poll (to avoid artifacts when bouncing between
CPUs). I haven't done any real statistics here -- I just ran them
in a loop and picked the fastest results that didn't look like
outliers. Unpatched means commit a4eb8b993554, so all the
bookkeeping overhead is gone.
ping-pong between two mms on the same CPU using eventfd:
patched: 1.22µs
patched, nopcid: 1.33µs
unpatched: 1.34µs
Same ping-pong, but now touch 512 pages (all zero-page to minimize
cache misses) each iteration. dTLB misses are measured by
dtlb_load_misses.miss_causes_a_walk:
patched: 1.8µs 11M dTLB misses
patched, nopcid: 6.2µs, 207M dTLB misses
unpatched: 6.1µs, 190M dTLB misses
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Nadav Amit <nadav.amit@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/9ee75f17a81770feed616358e6860d98a2a5b1e7.1500957502.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-25 11:41:38 +07:00
|
|
|
u16 loaded_mm_asid;
|
|
|
|
u16 next_asid;
|
2014-10-25 05:58:08 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Access to this CR4 shadow and to H/W CR4 is protected by
|
|
|
|
* disabling interrupts when modifying either one.
|
|
|
|
*/
|
|
|
|
unsigned long cr4;
|
2017-06-29 22:53:16 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This is a list of all contexts that might exist in the TLB.
|
x86/mm: Implement PCID based optimization: try to preserve old TLB entries using PCID
PCID is a "process context ID" -- it's what other architectures call
an address space ID. Every non-global TLB entry is tagged with a
PCID, only TLB entries that match the currently selected PCID are
used, and we can switch PGDs without flushing the TLB. x86's
PCID is 12 bits.
This is an unorthodox approach to using PCID. x86's PCID is far too
short to uniquely identify a process, and we can't even really
uniquely identify a running process because there are monster
systems with over 4096 CPUs. To make matters worse, past attempts
to use all 12 PCID bits have resulted in slowdowns instead of
speedups.
This patch uses PCID differently. We use a PCID to identify a
recently-used mm on a per-cpu basis. An mm has no fixed PCID
binding at all; instead, we give it a fresh PCID each time it's
loaded except in cases where we want to preserve the TLB, in which
case we reuse a recent value.
Here are some benchmark results, done on a Skylake laptop at 2.3 GHz
(turbo off, intel_pstate requesting max performance) under KVM with
the guest using idle=poll (to avoid artifacts when bouncing between
CPUs). I haven't done any real statistics here -- I just ran them
in a loop and picked the fastest results that didn't look like
outliers. Unpatched means commit a4eb8b993554, so all the
bookkeeping overhead is gone.
ping-pong between two mms on the same CPU using eventfd:
patched: 1.22µs
patched, nopcid: 1.33µs
unpatched: 1.34µs
Same ping-pong, but now touch 512 pages (all zero-page to minimize
cache misses) each iteration. dTLB misses are measured by
dtlb_load_misses.miss_causes_a_walk:
patched: 1.8µs 11M dTLB misses
patched, nopcid: 6.2µs, 207M dTLB misses
unpatched: 6.1µs, 190M dTLB misses
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Nadav Amit <nadav.amit@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/9ee75f17a81770feed616358e6860d98a2a5b1e7.1500957502.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-25 11:41:38 +07:00
|
|
|
* There is one per ASID that we use, and the ASID (what the
|
|
|
|
* CPU calls PCID) is the index into ctxts.
|
2017-06-29 22:53:16 +07:00
|
|
|
*
|
|
|
|
* For each context, ctx_id indicates which mm the TLB's user
|
|
|
|
* entries came from. As an invariant, the TLB will never
|
|
|
|
* contain entries that are out-of-date as when that mm reached
|
|
|
|
* the tlb_gen in the list.
|
|
|
|
*
|
|
|
|
* To be clear, this means that it's legal for the TLB code to
|
|
|
|
* flush the TLB without updating tlb_gen. This can happen
|
|
|
|
* (for now, at least) due to paravirt remote flushes.
|
x86/mm: Implement PCID based optimization: try to preserve old TLB entries using PCID
PCID is a "process context ID" -- it's what other architectures call
an address space ID. Every non-global TLB entry is tagged with a
PCID, only TLB entries that match the currently selected PCID are
used, and we can switch PGDs without flushing the TLB. x86's
PCID is 12 bits.
This is an unorthodox approach to using PCID. x86's PCID is far too
short to uniquely identify a process, and we can't even really
uniquely identify a running process because there are monster
systems with over 4096 CPUs. To make matters worse, past attempts
to use all 12 PCID bits have resulted in slowdowns instead of
speedups.
This patch uses PCID differently. We use a PCID to identify a
recently-used mm on a per-cpu basis. An mm has no fixed PCID
binding at all; instead, we give it a fresh PCID each time it's
loaded except in cases where we want to preserve the TLB, in which
case we reuse a recent value.
Here are some benchmark results, done on a Skylake laptop at 2.3 GHz
(turbo off, intel_pstate requesting max performance) under KVM with
the guest using idle=poll (to avoid artifacts when bouncing between
CPUs). I haven't done any real statistics here -- I just ran them
in a loop and picked the fastest results that didn't look like
outliers. Unpatched means commit a4eb8b993554, so all the
bookkeeping overhead is gone.
ping-pong between two mms on the same CPU using eventfd:
patched: 1.22µs
patched, nopcid: 1.33µs
unpatched: 1.34µs
Same ping-pong, but now touch 512 pages (all zero-page to minimize
cache misses) each iteration. dTLB misses are measured by
dtlb_load_misses.miss_causes_a_walk:
patched: 1.8µs 11M dTLB misses
patched, nopcid: 6.2µs, 207M dTLB misses
unpatched: 6.1µs, 190M dTLB misses
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Nadav Amit <nadav.amit@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/9ee75f17a81770feed616358e6860d98a2a5b1e7.1500957502.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-25 11:41:38 +07:00
|
|
|
*
|
|
|
|
* NB: context 0 is a bit special, since it's also used by
|
|
|
|
* various bits of init code. This is fine -- code that
|
|
|
|
* isn't aware of PCID will end up harmlessly flushing
|
|
|
|
* context 0.
|
2017-06-29 22:53:16 +07:00
|
|
|
*/
|
x86/mm: Implement PCID based optimization: try to preserve old TLB entries using PCID
PCID is a "process context ID" -- it's what other architectures call
an address space ID. Every non-global TLB entry is tagged with a
PCID, only TLB entries that match the currently selected PCID are
used, and we can switch PGDs without flushing the TLB. x86's
PCID is 12 bits.
This is an unorthodox approach to using PCID. x86's PCID is far too
short to uniquely identify a process, and we can't even really
uniquely identify a running process because there are monster
systems with over 4096 CPUs. To make matters worse, past attempts
to use all 12 PCID bits have resulted in slowdowns instead of
speedups.
This patch uses PCID differently. We use a PCID to identify a
recently-used mm on a per-cpu basis. An mm has no fixed PCID
binding at all; instead, we give it a fresh PCID each time it's
loaded except in cases where we want to preserve the TLB, in which
case we reuse a recent value.
Here are some benchmark results, done on a Skylake laptop at 2.3 GHz
(turbo off, intel_pstate requesting max performance) under KVM with
the guest using idle=poll (to avoid artifacts when bouncing between
CPUs). I haven't done any real statistics here -- I just ran them
in a loop and picked the fastest results that didn't look like
outliers. Unpatched means commit a4eb8b993554, so all the
bookkeeping overhead is gone.
ping-pong between two mms on the same CPU using eventfd:
patched: 1.22µs
patched, nopcid: 1.33µs
unpatched: 1.34µs
Same ping-pong, but now touch 512 pages (all zero-page to minimize
cache misses) each iteration. dTLB misses are measured by
dtlb_load_misses.miss_causes_a_walk:
patched: 1.8µs 11M dTLB misses
patched, nopcid: 6.2µs, 207M dTLB misses
unpatched: 6.1µs, 190M dTLB misses
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Nadav Amit <nadav.amit@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/9ee75f17a81770feed616358e6860d98a2a5b1e7.1500957502.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-25 11:41:38 +07:00
|
|
|
struct tlb_context ctxs[TLB_NR_DYN_ASIDS];
|
2014-10-25 05:58:08 +07:00
|
|
|
};
|
|
|
|
DECLARE_PER_CPU_SHARED_ALIGNED(struct tlb_state, cpu_tlbstate);
|
|
|
|
|
|
|
|
/* Initialize cr4 shadow for this CPU. */
|
|
|
|
static inline void cr4_init_shadow(void)
|
|
|
|
{
|
2016-09-30 02:48:12 +07:00
|
|
|
this_cpu_write(cpu_tlbstate.cr4, __read_cr4());
|
2014-10-25 05:58:08 +07:00
|
|
|
}
|
|
|
|
|
2014-10-25 05:58:07 +07:00
|
|
|
/* Set in this cpu's CR4. */
|
|
|
|
static inline void cr4_set_bits(unsigned long mask)
|
|
|
|
{
|
|
|
|
unsigned long cr4;
|
|
|
|
|
2014-10-25 05:58:08 +07:00
|
|
|
cr4 = this_cpu_read(cpu_tlbstate.cr4);
|
|
|
|
if ((cr4 | mask) != cr4) {
|
|
|
|
cr4 |= mask;
|
|
|
|
this_cpu_write(cpu_tlbstate.cr4, cr4);
|
|
|
|
__write_cr4(cr4);
|
|
|
|
}
|
2014-10-25 05:58:07 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Clear in this cpu's CR4. */
|
|
|
|
static inline void cr4_clear_bits(unsigned long mask)
|
|
|
|
{
|
|
|
|
unsigned long cr4;
|
|
|
|
|
2014-10-25 05:58:08 +07:00
|
|
|
cr4 = this_cpu_read(cpu_tlbstate.cr4);
|
|
|
|
if ((cr4 & ~mask) != cr4) {
|
|
|
|
cr4 &= ~mask;
|
|
|
|
this_cpu_write(cpu_tlbstate.cr4, cr4);
|
|
|
|
__write_cr4(cr4);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-02-14 15:11:04 +07:00
|
|
|
static inline void cr4_toggle_bits(unsigned long mask)
|
|
|
|
{
|
|
|
|
unsigned long cr4;
|
|
|
|
|
|
|
|
cr4 = this_cpu_read(cpu_tlbstate.cr4);
|
|
|
|
cr4 ^= mask;
|
|
|
|
this_cpu_write(cpu_tlbstate.cr4, cr4);
|
|
|
|
__write_cr4(cr4);
|
|
|
|
}
|
|
|
|
|
2014-10-25 05:58:08 +07:00
|
|
|
/* Read the CR4 shadow. */
|
|
|
|
static inline unsigned long cr4_read_shadow(void)
|
|
|
|
{
|
|
|
|
return this_cpu_read(cpu_tlbstate.cr4);
|
2014-10-25 05:58:07 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Save some of cr4 feature set we're using (e.g. Pentium 4MB
|
|
|
|
* enable and PPro Global page enable), so that any CPU's that boot
|
|
|
|
* up after us can get the correct flags. This should only be used
|
|
|
|
* during boot on the boot cpu.
|
|
|
|
*/
|
|
|
|
extern unsigned long mmu_cr4_features;
|
|
|
|
extern u32 *trampoline_cr4_features;
|
|
|
|
|
|
|
|
static inline void cr4_set_bits_and_update_boot(unsigned long mask)
|
|
|
|
{
|
|
|
|
mmu_cr4_features |= mask;
|
|
|
|
if (trampoline_cr4_features)
|
|
|
|
*trampoline_cr4_features = mmu_cr4_features;
|
|
|
|
cr4_set_bits(mask);
|
|
|
|
}
|
|
|
|
|
2008-01-30 19:30:35 +07:00
|
|
|
static inline void __native_flush_tlb(void)
|
|
|
|
{
|
2016-08-05 20:37:39 +07:00
|
|
|
/*
|
|
|
|
* If current->mm == NULL then we borrow a mm which may change during a
|
|
|
|
* task switch and therefore we must not be preempted while we write CR3
|
|
|
|
* back:
|
|
|
|
*/
|
|
|
|
preempt_disable();
|
2017-06-13 00:26:14 +07:00
|
|
|
native_write_cr3(__native_read_cr3());
|
2016-08-05 20:37:39 +07:00
|
|
|
preempt_enable();
|
2008-01-30 19:30:35 +07:00
|
|
|
}
|
|
|
|
|
2012-12-21 14:44:27 +07:00
|
|
|
static inline void __native_flush_tlb_global_irq_disabled(void)
|
|
|
|
{
|
|
|
|
unsigned long cr4;
|
|
|
|
|
2014-10-25 05:58:08 +07:00
|
|
|
cr4 = this_cpu_read(cpu_tlbstate.cr4);
|
2012-12-21 14:44:27 +07:00
|
|
|
/* clear PGE */
|
|
|
|
native_write_cr4(cr4 & ~X86_CR4_PGE);
|
|
|
|
/* write old PGE again and flush TLBs */
|
|
|
|
native_write_cr4(cr4);
|
|
|
|
}
|
|
|
|
|
2008-01-30 19:30:35 +07:00
|
|
|
static inline void __native_flush_tlb_global(void)
|
|
|
|
{
|
2008-05-13 02:21:15 +07:00
|
|
|
unsigned long flags;
|
2008-01-30 19:30:35 +07:00
|
|
|
|
2016-01-30 02:42:59 +07:00
|
|
|
if (static_cpu_has(X86_FEATURE_INVPCID)) {
|
|
|
|
/*
|
|
|
|
* Using INVPCID is considerably faster than a pair of writes
|
|
|
|
* to CR4 sandwiched inside an IRQ flag save/restore.
|
|
|
|
*/
|
|
|
|
invpcid_flush_all();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2008-05-13 02:21:15 +07:00
|
|
|
/*
|
|
|
|
* Read-modify-write to CR4 - protect it from preemption and
|
|
|
|
* from interrupts. (Use the raw variant because this code can
|
|
|
|
* be called from deep inside debugging code.)
|
|
|
|
*/
|
|
|
|
raw_local_irq_save(flags);
|
|
|
|
|
2012-12-21 14:44:27 +07:00
|
|
|
__native_flush_tlb_global_irq_disabled();
|
2008-05-13 02:21:15 +07:00
|
|
|
|
|
|
|
raw_local_irq_restore(flags);
|
2008-01-30 19:30:35 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __native_flush_tlb_single(unsigned long addr)
|
|
|
|
{
|
2008-03-23 15:03:45 +07:00
|
|
|
asm volatile("invlpg (%0)" ::"r" (addr) : "memory");
|
2008-01-30 19:30:35 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __flush_tlb_all(void)
|
|
|
|
{
|
x86/tlb: Fix tlb flushing when lguest clears PGE
Fengguang reported random corruptions from various locations on x86-32
after commits d2852a224050 ("arch: add ARCH_HAS_SET_MEMORY config") and
9d876e79df6a ("bpf: fix unlocking of jited image when module ronx not set")
that uses the former. While x86-32 doesn't have a JIT like x86_64, the
bpf_prog_lock_ro() and bpf_prog_unlock_ro() got enabled due to
ARCH_HAS_SET_MEMORY, whereas Fengguang's test kernel doesn't have module
support built in and therefore never had the DEBUG_SET_MODULE_RONX setting
enabled.
After investigating the crashes further, it turned out that using
set_memory_ro() and set_memory_rw() didn't have the desired effect, for
example, setting the pages as read-only on x86-32 would still let
probe_kernel_write() succeed without error. This behavior would manifest
itself in situations where the vmalloc'ed buffer was accessed prior to
set_memory_*() such as in case of bpf_prog_alloc(). In cases where it
wasn't, the page attribute changes seemed to have taken effect, leading to
the conclusion that a TLB invalidate didn't happen. Moreover, it turned out
that this issue reproduced with qemu in "-cpu kvm64" mode, but not for
"-cpu host". When the issue occurs, change_page_attr_set_clr() did trigger
a TLB flush as expected via __flush_tlb_all() through cpa_flush_range(),
though.
There are 3 variants for issuing a TLB flush: invpcid_flush_all() (depends
on CPU feature bits X86_FEATURE_INVPCID, X86_FEATURE_PGE), cr4 based flush
(depends on X86_FEATURE_PGE), and cr3 based flush. For "-cpu host" case in
my setup, the flush used invpcid_flush_all() variant, whereas for "-cpu
kvm64", the flush was cr4 based. Switching the kvm64 case to cr3 manually
worked fine, and further investigating the cr4 one turned out that
X86_CR4_PGE bit was not set in cr4 register, meaning the
__native_flush_tlb_global_irq_disabled() wrote cr4 twice with the same
value instead of clearing X86_CR4_PGE in the first write to trigger the
flush.
It turned out that X86_CR4_PGE was cleared from cr4 during init from
lguest_arch_host_init() via adjust_pge(). The X86_FEATURE_PGE bit is also
cleared from there due to concerns of using PGE in guest kernel that can
lead to hard to trace bugs (see bff672e630a0 ("lguest: documentation V:
Host") in init()). The CPU feature bits are cleared in dynamic
boot_cpu_data, but they never propagated to __flush_tlb_all() as it uses
static_cpu_has() instead of boot_cpu_has() for testing which variant of TLB
flushing to use, meaning they still used the old setting of the host
kernel.
Clearing via setup_clear_cpu_cap(X86_FEATURE_PGE) so this would propagate
to static_cpu_has() checks is too late at this point as sections have been
patched already, so for now, it seems reasonable to switch back to
boot_cpu_has(X86_FEATURE_PGE) as it was prior to commit c109bf95992b
("x86/cpufeature: Remove cpu_has_pge"). This lets the TLB flush trigger via
cr3 as originally intended, properly makes the new page attributes visible
and thus fixes the crashes seen by Fengguang.
Fixes: c109bf95992b ("x86/cpufeature: Remove cpu_has_pge")
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: bp@suse.de
Cc: Kees Cook <keescook@chromium.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: lkp@01.org
Cc: Laura Abbott <labbott@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernrl.org/r/20170301125426.l4nf65rx4wahohyl@wfg-t540p.sh.intel.com
Link: http://lkml.kernel.org/r/25c41ad9eca164be4db9ad84f768965b7eb19d9e.1489191673.git.daniel@iogearbox.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-03-11 07:31:19 +07:00
|
|
|
if (boot_cpu_has(X86_FEATURE_PGE))
|
2008-01-30 19:30:35 +07:00
|
|
|
__flush_tlb_global();
|
|
|
|
else
|
|
|
|
__flush_tlb();
|
2017-06-29 22:53:21 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: if we somehow had PCID but not PGE, then this wouldn't work --
|
|
|
|
* we'd end up flushing kernel translations for the current ASID but
|
|
|
|
* we might fail to flush kernel translations for other cached ASIDs.
|
|
|
|
*
|
|
|
|
* To avoid this issue, we force PCID off if PGE is off.
|
|
|
|
*/
|
2008-01-30 19:30:35 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __flush_tlb_one(unsigned long addr)
|
|
|
|
{
|
2014-01-22 05:33:16 +07:00
|
|
|
count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ONE);
|
2013-06-04 13:28:18 +07:00
|
|
|
__flush_tlb_single(addr);
|
2008-01-30 19:30:35 +07:00
|
|
|
}
|
|
|
|
|
2012-05-10 17:01:59 +07:00
|
|
|
#define TLB_FLUSH_ALL -1UL
|
2008-01-30 19:30:35 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* TLB flushing:
|
|
|
|
*
|
|
|
|
* - flush_tlb_all() flushes all processes TLBs
|
|
|
|
* - flush_tlb_mm(mm) flushes the specified mm context TLB's
|
|
|
|
* - 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
|
2017-05-29 00:00:10 +07:00
|
|
|
* - flush_tlb_others(cpumask, info) flushes TLBs on other cpus
|
2008-01-30 19:30:35 +07:00
|
|
|
*
|
|
|
|
* ..but the i386 has somewhat limited tlb flushing capabilities,
|
|
|
|
* and page-granular flushes are available only on i486 and up.
|
|
|
|
*/
|
2017-05-29 00:00:10 +07:00
|
|
|
struct flush_tlb_info {
|
2017-06-29 22:53:16 +07:00
|
|
|
/*
|
|
|
|
* We support several kinds of flushes.
|
|
|
|
*
|
|
|
|
* - Fully flush a single mm. .mm will be set, .end will be
|
|
|
|
* TLB_FLUSH_ALL, and .new_tlb_gen will be the tlb_gen to
|
|
|
|
* which the IPI sender is trying to catch us up.
|
|
|
|
*
|
|
|
|
* - Partially flush a single mm. .mm will be set, .start and
|
|
|
|
* .end will indicate the range, and .new_tlb_gen will be set
|
|
|
|
* such that the changes between generation .new_tlb_gen-1 and
|
|
|
|
* .new_tlb_gen are entirely contained in the indicated range.
|
|
|
|
*
|
|
|
|
* - Fully flush all mms whose tlb_gens have been updated. .mm
|
|
|
|
* will be NULL, .end will be TLB_FLUSH_ALL, and .new_tlb_gen
|
|
|
|
* will be zero.
|
|
|
|
*/
|
|
|
|
struct mm_struct *mm;
|
|
|
|
unsigned long start;
|
|
|
|
unsigned long end;
|
|
|
|
u64 new_tlb_gen;
|
2017-05-29 00:00:10 +07:00
|
|
|
};
|
|
|
|
|
2008-01-30 19:30:35 +07:00
|
|
|
#define local_flush_tlb() __flush_tlb()
|
|
|
|
|
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 flush_tlb_mm(mm) flush_tlb_mm_range(mm, 0UL, TLB_FLUSH_ALL, 0UL)
|
|
|
|
|
|
|
|
#define flush_tlb_range(vma, start, end) \
|
|
|
|
flush_tlb_mm_range(vma->vm_mm, start, end, vma->vm_flags)
|
|
|
|
|
2008-01-30 19:30:35 +07:00
|
|
|
extern void flush_tlb_all(void);
|
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
|
|
|
extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
|
|
|
|
unsigned long end, unsigned long vmflag);
|
2012-06-28 08:02:24 +07:00
|
|
|
extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
|
2008-01-30 19:30:35 +07:00
|
|
|
|
2017-05-23 05:30:01 +07:00
|
|
|
static inline void flush_tlb_page(struct vm_area_struct *vma, unsigned long a)
|
|
|
|
{
|
|
|
|
flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, VM_NONE);
|
|
|
|
}
|
|
|
|
|
2009-01-11 12:58:09 +07:00
|
|
|
void native_flush_tlb_others(const struct cpumask *cpumask,
|
2017-05-29 00:00:10 +07:00
|
|
|
const struct flush_tlb_info *info);
|
2008-01-30 19:30:35 +07:00
|
|
|
|
2017-05-23 05:30:03 +07:00
|
|
|
static inline void arch_tlbbatch_add_mm(struct arch_tlbflush_unmap_batch *batch,
|
|
|
|
struct mm_struct *mm)
|
|
|
|
{
|
2017-06-29 22:53:15 +07:00
|
|
|
inc_mm_tlb_gen(mm);
|
2017-05-23 05:30:03 +07:00
|
|
|
cpumask_or(&batch->cpumask, &batch->cpumask, mm_cpumask(mm));
|
|
|
|
}
|
|
|
|
|
|
|
|
extern void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch);
|
|
|
|
|
2008-01-30 19:30:35 +07:00
|
|
|
#ifndef CONFIG_PARAVIRT
|
2017-05-29 00:00:10 +07:00
|
|
|
#define flush_tlb_others(mask, info) \
|
|
|
|
native_flush_tlb_others(mask, info)
|
2007-10-11 16:20:03 +07:00
|
|
|
#endif
|
2008-01-30 19:30:35 +07:00
|
|
|
|
2008-10-23 12:26:29 +07:00
|
|
|
#endif /* _ASM_X86_TLBFLUSH_H */
|