From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752591AbdEHQgx (ORCPT ); Mon, 8 May 2017 12:36:53 -0400 Received: from mail-pg0-f66.google.com ([74.125.83.66]:36672 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751463AbdEHQgv (ORCPT ); Mon, 8 May 2017 12:36:51 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [RFC 00/10] x86 TLB flush cleanups, moving toward PCID support From: Nadav Amit In-Reply-To: Date: Mon, 8 May 2017 09:36:47 -0700 Cc: X86 ML , "linux-kernel@vger.kernel.org" , Borislav Petkov , Linus Torvalds , Andrew Morton , Mel Gorman , "linux-mm@kvack.org" Message-Id: <469C2BEE-5B6C-4351-8BC9-17796A072964@gmail.com> References: To: Andy Lutomirski X-Mailer: Apple Mail (2.3273) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v48Gav38008480 > On May 7, 2017, at 5:38 AM, Andy Lutomirski 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. - Don’t expect too much from concurrent TLB invalidations. In many cases the IPI latency dominates the overhead from my experience. Regards, Nadav