Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5676478imm; Tue, 26 Jun 2018 15:58:39 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJTkdTedm7hOytWcGKFN6oZ3lofmzfXjwSKmXzwEakAvZai3UFtojsHSdVqpcPZtIE+EPWh X-Received: by 2002:a17:902:44a4:: with SMTP id l33-v6mr3515847pld.134.1530053919594; Tue, 26 Jun 2018 15:58:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530053919; cv=none; d=google.com; s=arc-20160816; b=xaNplHF8wHIXQ36l8lz0EZbCR6mW2yq1givimPW+LREXlTv6rptlPvrVV+PiFYvIw0 nV4aRJG90/74Jp6FMKtI6k0L1i23Jf96gfiirii7mz3P6yuAnpNlEkyqqjSJ0+EWiKfm c3S4ReQ/a2PNC699tyRd6m9xI0fBh+avF0f3KZqnk8fuoM4UVB34EjUieIGYytoS6Ty+ amD/HkM4fEdjdGLgQSvFkaLQ1awGBF3D/+HsaGhfbnJG1hWiYCmlH6XvBDxKpsXNZOmb VWX1j0Ain/iF3PILIQklbUPDY7Ct3IY6J5CeKNGy1Z9G+WC1ncCv5qtbJJsRv1ngQ/AA BlLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=y369oZL8t2FWvu4QRs+JiL0j46X2GNTXa5/TUJS5H1Y=; b=WTe0VqZZwyPzXrjOUTKHAxyBuzmtQYp1eCg57WWB1TjMCVjztsJ/MJMwsy44png0oJ aAhwJ8awHqc+fDCuHCwB3zH3sClAIsXSNX6j7F1HdPPhhEuXw3J2nPZE3Ed3Pd1F6BRr c3sOsmxVu1e27BHFuEoOWvMAHi3b8yshwnBlbvAY/xDb4pA8KC+hLChLbNJHH+kaxy85 HBcVAbVlvJbiCdkBXwB/ma80pBnfqjTFDbLY7OC3jGuAxvFJO9aR+IDjYoZ0jI3UqstD T3/4KGRgNf1UegxPV2+kVGEGBBGfa4ZDxArnLSulSbRlC5AHqL8qyCfUWYIYbqbOpKAW OrnQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m15-v6si2112688pgv.166.2018.06.26.15.58.25; Tue, 26 Jun 2018 15:58:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933776AbeFZRbs (ORCPT + 99 others); Tue, 26 Jun 2018 13:31:48 -0400 Received: from shelob.surriel.com ([96.67.55.147]:36880 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933726AbeFZRbn (ORCPT ); Tue, 26 Jun 2018 13:31:43 -0400 Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fXroS-0005n2-JW; Tue, 26 Jun 2018 13:31:32 -0400 From: Rik van Riel To: linux-kernel@vger.kernel.org Cc: x86@kernel.org, luto@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, kernel-team@fb.com, tglx@linutronix.de, efault@gmx.de, songliubraving@fb.com, Rik van Riel Subject: [PATCH 4/6] x86,tlb: only send page table free TLB flush to lazy TLB CPUs Date: Tue, 26 Jun 2018 13:31:24 -0400 Message-Id: <20180626173126.12296-5-riel@surriel.com> X-Mailer: git-send-email 2.14.4 In-Reply-To: <20180626173126.12296-1-riel@surriel.com> References: <20180626173126.12296-1-riel@surriel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org CPUs in !is_lazy have either received TLB flush IPIs earlier on during the munmap (when the user memory was unmapped), or have context switched and reloaded during that stage of the munmap. Page table free TLB flushes only need to be sent to CPUs in lazy TLB mode, which TLB contents might not yet be up to date yet. Signed-off-by: Rik van Riel Tested-by: Song Liu --- arch/x86/mm/tlb.c | 38 +++++++++++++++++++++++++++++++++++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index 137a2c62c75b..03512772395f 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -707,14 +707,46 @@ void tlb_flush_remove_tables_local(void *arg) } } +void mm_fill_lazy_tlb_cpu_mask(struct mm_struct *mm, struct cpumask* lazy_cpus) +{ + int cpu; + + for_each_cpu(cpu, mm_cpumask(mm)) { + if (!per_cpu(cpu_tlbstate.is_lazy, cpu)) + cpumask_set_cpu(cpu, lazy_cpus); + } +} + void tlb_flush_remove_tables(struct mm_struct *mm) { int cpu = get_cpu(); + cpumask_var_t lazy_cpus; + + if (cpumask_any_but(mm_cpumask(mm), cpu) >= nr_cpu_ids) + return; + + if (!zalloc_cpumask_var(&lazy_cpus, GFP_ATOMIC)) { + /* + * If the cpumask allocation fails, do a brute force flush + * on all the CPUs that have this mm loaded. + */ + smp_call_function_many(mm_cpumask(mm), + tlb_flush_remove_tables_local, (void *)mm, 1); + return; + } + /* - * XXX: this really only needs to be called for CPUs in lazy TLB mode. + * CPUs with !is_lazy either received a TLB flush IPI while the user + * pages in this address range were unmapped, or have context switched + * and reloaded %CR3 since then. + * + * Shootdown IPIs at page table freeing time only need to be sent to + * CPUs that may have out of date TLB contents. */ - if (cpumask_any_but(mm_cpumask(mm), cpu) < nr_cpu_ids) - smp_call_function_many(mm_cpumask(mm), tlb_flush_remove_tables_local, (void *)mm, 1); + mm_fill_lazy_tlb_cpu_mask(mm, lazy_cpus); + smp_call_function_many(lazy_cpus, + tlb_flush_remove_tables_local, (void *)mm, 1); + free_cpumask_var(lazy_cpus); put_cpu(); } -- 2.14.4