Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753512AbdFWH3m (ORCPT ); Fri, 23 Jun 2017 03:29:42 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:58730 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751230AbdFWH3l (ORCPT ); Fri, 23 Jun 2017 03:29:41 -0400 Date: Fri, 23 Jun 2017 09:29:35 +0200 (CEST) From: Thomas Gleixner To: Andy Lutomirski cc: X86 ML , "linux-kernel@vger.kernel.org" , Borislav Petkov , Linus Torvalds , Andrew Morton , Mel Gorman , "linux-mm@kvack.org" , Nadav Amit , Rik van Riel , Dave Hansen , Arjan van de Ven , Peter Zijlstra Subject: Re: [PATCH v3 11/11] x86/mm: Try to preserve old TLB entries using PCID In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1517 Lines: 30 On Thu, 22 Jun 2017, Andy Lutomirski wrote: > On Thu, Jun 22, 2017 at 2:22 PM, Thomas Gleixner wrote: > > On Thu, 22 Jun 2017, Andy Lutomirski wrote: > >> On Thu, Jun 22, 2017 at 5:21 AM, Thomas Gleixner wrote: > >> > Now one other optimization which should be trivial to add is to keep the 4 > >> > asid context entries in cpu_tlbstate and cache the last asid in thread > >> > info. If that's still valid then use it otherwise unconditionally get a new > >> > one. That avoids the whole loop machinery and thread info is cache hot in > >> > the context switch anyway. Delta patch on top of your version below. > >> > >> I'm not sure I understand. If an mm has ASID 0 on CPU 0 and ASID 1 on > >> CPU 1 and a thread in that mm bounces back and forth between those > >> CPUs, won't your patch cause it to flush every time? > > > > Yeah, I was too focussed on the non migratory case, where two tasks from > > different processes play rapid ping pong. That's what I was looking at for > > various reasons. > > > > There the cached asid really helps by avoiding the loop completely, but > > yes, the search needs to be done for the bouncing between CPUs case. > > > > So maybe a combo of those might be interesting. > > > > I'm not too worried about optimizing away the loop. It's a loop over > four or six things that are all in cachelines that we need anyway. I > suspect that we'll never be able to see it in any microbenchmark, let > alone real application. Fair enough.