Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751923AbdGEQKZ (ORCPT ); Wed, 5 Jul 2017 12:10:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:55478 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751678AbdGEQKX (ORCPT ); Wed, 5 Jul 2017 12:10:23 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8863722C8B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 In-Reply-To: <20170705122506.GG4941@worktop> References: <20170705122506.GG4941@worktop> From: Andy Lutomirski Date: Wed, 5 Jul 2017 09:10:00 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 10/10] x86/mm: Try to preserve old TLB entries using PCID To: Peter Zijlstra Cc: Andy Lutomirski , 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1729 Lines: 43 On Wed, Jul 5, 2017 at 5:25 AM, Peter Zijlstra wrote: > On Thu, Jun 29, 2017 at 08:53:22AM -0700, Andy Lutomirski wrote: >> +static void choose_new_asid(struct mm_struct *next, u64 next_tlb_gen, >> + u16 *new_asid, bool *need_flush) >> +{ >> + u16 asid; >> + >> + if (!static_cpu_has(X86_FEATURE_PCID)) { >> + *new_asid = 0; >> + *need_flush = true; >> + return; >> + } >> + >> + for (asid = 0; asid < TLB_NR_DYN_ASIDS; asid++) { >> + if (this_cpu_read(cpu_tlbstate.ctxs[asid].ctx_id) != >> + next->context.ctx_id) >> + continue; >> + >> + *new_asid = asid; >> + *need_flush = (this_cpu_read(cpu_tlbstate.ctxs[asid].tlb_gen) < >> + next_tlb_gen); >> + return; >> + } >> + >> + /* >> + * We don't currently own an ASID slot on this CPU. >> + * Allocate a slot. >> + */ >> + *new_asid = this_cpu_add_return(cpu_tlbstate.next_asid, 1) - 1; > > So this basically RR the ASID slots. Have you tried slightly more > complex replacement policies like CLOCK ? No, mainly because I'm lazy and because CLOCK requires scavenging a bit. (Which we can certainly do, but it will further complicate the code.) It could be worth playing with better replacement algorithms as a followup, though. I've also considered a slight elaboration of RR in which we make sure not to reuse the most recent ASID slot, which would guarantee that, if we switch from task A to B and back to A, we don't flush on the way back to A. (Currently, if B is not in the cache, there's a 1/6 chance we'll flush on the way back.)