Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1305078 > unrolled thread

[RFC 00/13] x86/mm: PCID and INVPCID

Back to article view | Back to linux.kernel

Contents

  [RFC 00/13] x86/mm: PCID and INVPCID Andy Lutomirski <luto@kernel.org> - 2016-01-09 00:20 +0100
    Re: [RFC 00/13] x86/mm: PCID and INVPCID Linus Torvalds <torvalds@linux-foundation.org> - 2016-01-09 00:40 +0100
      Re: [RFC 00/13] x86/mm: PCID and INVPCID Andy Lutomirski <luto@amacapital.net> - 2016-01-09 00:40 +0100
        Re: [RFC 00/13] x86/mm: PCID and INVPCID Linus Torvalds <torvalds@linux-foundation.org> - 2016-01-09 00:50 +0100

#1305078 — [RFC 00/13] x86/mm: PCID and INVPCID

Here's my PCID and INVPCID work-in-progress.  It seems to work well
enough to play with it.  (That is, I'm not aware of anything wrong
with it, although it may eat your data.)

PCID and INVPCID use are orthogonal here.  INVPCID is a
straightforward speedup for global TLB flushes.  Other than that, I
don't use INVPCID at all, since it seems slower than just
manipulating CR3 carefully, at least on my Skylake laptop.

Please play around and suggest (and run?) good benchmarks.  It seems
to save around 100ns on cross-process context switches for me.
Unfortunately, we suck at context switches in general, so this is,
at best, a little over a 10% speedup.  Most of the time is spent in
the scheduler, not in arch code.

Andy Lutomirski (13):
  x86/paravirt: Turn KASAN off for parvirt.o
  x86/mm: Add INVPCID helpers
  x86/mm: Add a noinvpcid option to turn off INVPCID
  x86/mm: If INVPCID is available, use it to flush global mappings
  x86/mm: Add barriers and document switch_mm-vs-flush synchronization
  x86/mm: Disable PCID on 32-bit kernels
  x86/mm: Add nopcid to turn off PCID
  x86/mm: Teach CR3 readers about PCID
  x86/mm: Disable interrupts when flushing the TLB using CR3
  x86/mm: Factor out remote TLB flushing
  x86/mm: Build arch/x86/mm/tlb.c even on !SMP
  x86/mm: Uninline switch_mm
  x86/mm: Try to preserve old TLB entries using PCID

 Documentation/kernel-parameters.txt      |   4 +
 arch/x86/include/asm/disabled-features.h |   4 +-
 arch/x86/include/asm/mmu.h               |   7 +-
 arch/x86/include/asm/mmu_context.h       |  62 +-----
 arch/x86/include/asm/tlbflush.h          |  86 ++++++++
 arch/x86/kernel/Makefile                 |   1 +
 arch/x86/kernel/cpu/bugs.c               |   6 +
 arch/x86/kernel/cpu/common.c             |  38 ++++
 arch/x86/kernel/head64.c                 |   3 +-
 arch/x86/kernel/ldt.c                    |   2 +
 arch/x86/kernel/process_64.c             |   2 +
 arch/x86/mm/Makefile                     |   3 +-
 arch/x86/mm/fault.c                      |   8 +-
 arch/x86/mm/tlb.c                        | 324 +++++++++++++++++++++++++++++--
 14 files changed, 467 insertions(+), 83 deletions(-)

-- 
2.5.0

[toc] | [next] | [standalone]

#1305084

On Fri, Jan 8, 2016 at 3:15 PM, Andy Lutomirski <luto@kernel.org> wrote:
>
> Please play around and suggest (and run?) good benchmarks.  It seems
> to save around 100ns on cross-process context switches for me.

Interesting. There was reportedly (I never saw it) a test-patch to use
pcids inside of Intel a couple of years ago, and it never got outside
because it didn't make a difference.

Either things have changed (newer hardware with more pcids perhaps?)
or you did a better job at it.

              Linus

[toc] | [prev] | [next] | [standalone]

#1305085

On Fri, Jan 8, 2016 at 3:31 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Jan 8, 2016 at 3:15 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>
>> Please play around and suggest (and run?) good benchmarks.  It seems
>> to save around 100ns on cross-process context switches for me.
>
> Interesting. There was reportedly (I never saw it) a test-patch to use
> pcids inside of Intel a couple of years ago, and it never got outside
> because it didn't make a difference.

I have a copy of that patch, and my code works very differently.  I
only use 3 bits of PCID in this series.  I could probably reduce that
to 2 with little loss.  4 or more would be a waste.

>
> Either things have changed (newer hardware with more pcids perhaps?)
> or you did a better job at it.

On my Skylake laptop, all of the PCID bits appear to have at least
some effect.  Whether this means it gets hashed or whether this means
that all of the bits are real, I don't know.  I'll fiddle with it on
an older machine.

--Andy

[toc] | [prev] | [next] | [standalone]

#1305090

On Fri, Jan 8, 2016 at 3:36 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>
>> Either things have changed (newer hardware with more pcids perhaps?)
>> or you did a better job at it.
>
> On my Skylake laptop, all of the PCID bits appear to have at least
> some effect.  Whether this means it gets hashed or whether this means
> that all of the bits are real, I don't know.

They have always gotten hashed, and no the bits aren't real - hardware
doesn't actually have as many bits in the pcid as there are in cr3.

              Linus

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web