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


Groups > linux.kernel > #1638099

Re: [RFC 00/10] x86 TLB flush cleanups, moving toward PCID support

From Andy Lutomirski <luto@kernel.org>
Newsgroups linux.kernel
Subject Re: [RFC 00/10] x86 TLB flush cleanups, moving toward PCID support
Date 2017-05-09 14:50 +0200
Message-ID <tFcKu-1MB-15@gated-at.bofh.it> (permalink)
References <tECxj-3oj-5@gated-at.bofh.it> <tETRw-6jm-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, May 8, 2017 at 9:36 AM, Nadav Amit <nadav.amit@gmail.com> wrote:
>
>> On May 7, 2017, at 5:38 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>
>> As I've been working on polishing my PCID code, a major problem I've
>> encountered is that there are too many x86 TLB flushing code paths and
>> that they have too many inconsequential differences.  The result was
>> that earlier versions of the PCID code were a colossal mess and very
>> difficult to understand.
>>
>> This series goes a long way toward cleaning up the mess.  With all the
>> patches applied, there is a single function that contains the meat of
>> the code to flush the TLB on a given CPU, and all the tlb flushing
>> APIs call it for both local and remote CPUs.
>>
>> This series should only adversely affect the kernel in a couple of
>> minor ways:
>>
>> - It makes smp_mb() unconditional when flushing TLBs.  We used to
>>   use the TLB flush itself to mostly avoid smp_mb() on the initiating
>>   CPU.
>>
>> - On UP kernels, we lose the dubious optimization of inlining nerfed
>>   variants of all the TLB flush APIs.  This bloats the kernel a tiny
>>   bit, although it should increase performance, since the SMP
>>   versions were better.
>>
>> Patch 10 in here is a little bit off topic.  It's a cleanup that's
>> also needed before PCID can go in, but it's not directly about
>> TLB flushing.
>>
>> Thoughts?
>
> In general I like the changes. I needed to hack Linux TLB shootdowns for
> a research project just because I could not handle the code otherwise.
> I ended up doing some of changes that you have done.
>
> I just have two general comments:
>
> - You may want to consider merging the kernel mappings invalidation
>   with the userspace mappings invalidations as well, since there are
>   still code redundancies.
>

Hmm.  The code for kernel mappings is quite short, and I'm not sure
how well it would fit in if I tried to merge it.

> - Don’t expect too much from concurrent TLB invalidations. In many
>   cases the IPI latency dominates the overhead from my experience.
>

Fair enough.

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[RFC 00/10] x86 TLB flush cleanups, moving toward PCID support Andy Lutomirski <luto@kernel.org> - 2017-05-08 00:10 +0200
  [RFC 03/10] x86/mm: Make the batched unmap TLB flush API more generic Andy Lutomirski <luto@kernel.org> - 2017-05-08 00:10 +0200
    Re: [RFC 03/10] x86/mm: Make the batched unmap TLB flush API more  generic Dave Hansen <dave.hansen@intel.com> - 2017-05-08 17:40 +0200
      Re: [RFC 03/10] x86/mm: Make the batched unmap TLB flush API more generic Andy Lutomirski <luto@kernel.org> - 2017-05-09 15:10 +0200
        Re: [RFC 03/10] x86/mm: Make the batched unmap TLB flush API more  generic Mel Gorman <mgorman@suse.de> - 2017-05-09 16:50 +0200
        Re: [RFC 03/10] x86/mm: Make the batched unmap TLB flush API more  generic Dave Hansen <dave.hansen@intel.com> - 2017-05-09 19:20 +0200
          Re: [RFC 03/10] x86/mm: Make the batched unmap TLB flush API more generic Andy Lutomirski <luto@kernel.org> - 2017-05-10 01:00 +0200
  [RFC 07/10] x86/mm: Use new merged flush logic in arch_tlbbatch_flush() Andy Lutomirski <luto@kernel.org> - 2017-05-08 00:10 +0200
  [RFC 04/10] x86/mm: Pass flush_tlb_info to flush_tlb_others() etc Andy Lutomirski <luto@kernel.org> - 2017-05-08 00:10 +0200
    Re: [RFC 04/10] x86/mm: Pass flush_tlb_info to flush_tlb_others() etc Nadav Amit <nadav.amit@gmail.com> - 2017-05-11 22:10 +0200
  [RFC 05/10] x86/mm: Change the leave_mm() condition for local TLB flushes Andy Lutomirski <luto@kernel.org> - 2017-05-08 00:10 +0200
  [RFC 02/10] x86/mm: Reduce indentation in flush_tlb_func() Andy Lutomirski <luto@kernel.org> - 2017-05-08 00:10 +0200
  [RFC 08/10] x86/mm: Remove the UP tlbflush code; always use the formerly SMP code Andy Lutomirski <luto@kernel.org> - 2017-05-08 00:10 +0200
  [RFC 01/10] x86/mm: Reimplement flush_tlb_page() using flush_tlb_mm_range() Andy Lutomirski <luto@kernel.org> - 2017-05-08 00:10 +0200
    Re: [RFC 01/10] x86/mm: Reimplement flush_tlb_page() using  flush_tlb_mm_range() Borislav Petkov <bp@suse.de> - 2017-05-11 19:50 +0200
  [RFC 10/10] x86,kvm: Teach KVM's VMX code that CR3 isn't a constant Andy Lutomirski <luto@kernel.org> - 2017-05-08 00:20 +0200
  [RFC 06/10] x86/mm: Refactor flush_tlb_mm_range() to merge local and remote cases Andy Lutomirski <luto@kernel.org> - 2017-05-08 00:20 +0200
  Re: [RFC 00/10] x86 TLB flush cleanups, moving toward PCID support Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-08 01:00 +0200
  Re: [RFC 00/10] x86 TLB flush cleanups, moving toward PCID support Ingo Molnar <mingo@kernel.org> - 2017-05-08 01:50 +0200
  Re: [RFC 00/10] x86 TLB flush cleanups, moving toward PCID support Nadav Amit <nadav.amit@gmail.com> - 2017-05-08 18:40 +0200
    Re: [RFC 00/10] x86 TLB flush cleanups, moving toward PCID support Andy Lutomirski <luto@kernel.org> - 2017-05-09 14:50 +0200

csiph-web