Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3838119yba; Tue, 23 Apr 2019 10:25:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqyRUW+MgnFqZGGhxKHMo9koMxcFTRdj5vYCti2YYdCjVUbJf78o2QNXLkFKRQHQTLLFp4j7 X-Received: by 2002:a17:902:9898:: with SMTP id s24mr6313506plp.268.1556040313341; Tue, 23 Apr 2019 10:25:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556040313; cv=none; d=google.com; s=arc-20160816; b=vdnFP61eiYRXDPM275kBD1Y/C7JpONO464v6UhzvAOnPPhfLczbEzkE5yDRbkEIP+l Ht9XxTvIG+ZIl+Wb8tu4NGxYvYgei4+Lj4HyrmmZ94SCuO5Dlc1re9rJHuE3kPos2VsY 4DaAZJO3I7L5izDXWNNJDJgEAEC0R+371sTg7yUoPTogGTBN1XB5DHApDrNhQmN3uUFJ 9C7Pi2PZISRJIRyXyMCOOYgkNsrIBGRY3vA36EjQgi/S6vSM0ge6Gm7MuUhZmffxxCFv mn4Gb8DnMzlFc618saCeeoGQpYBgxdpQmxw660u4bkMeMDpBex8qeabnGgzJnwhCgbKZ +bAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=DYDu0b5LT73SDWHtyGYu0Neskt+odPkl2otFzW8nrgo=; b=Oi1ooei3Yj70HOmdf1sg+rhG7hO2AtS3dIQ6jENGZ97xkA0sE0rY9l5XuHVHANdgb7 PpymVMslFqwkQ0yZBtH1wzIwRHfG/T0fg/W3zCSm2OXGZfPxUTutTxsonzuqQ7rjqX6r +aJYJfqRA/44nY3XPujQCwIUu90RE12XhADMuphx37J0QbAuyC7XDzdjGaluB+o6T1JH 6bMn+/g97LS+B7mLvS7sJ3KdSv+J8dGoc6bCEqhGtORi9CAzOs18MXxgqTdDocdrcxKA IrZXJKVUlM9glPWKeutcxwGyOEw/Rwo9WYA03Zxfz0gxXmEjVYViQCtHscpQzLDgnIHo j/zA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=XXy3hiAA; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s79si16701675pfa.69.2019.04.23.10.24.59; Tue, 23 Apr 2019 10:25:13 -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; dkim=pass header.i=@kernel.org header.s=default header.b=XXy3hiAA; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729378AbfDWRYF (ORCPT + 99 others); Tue, 23 Apr 2019 13:24:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:54602 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728447AbfDWRYC (ORCPT ); Tue, 23 Apr 2019 13:24:02 -0400 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E30C521850 for ; Tue, 23 Apr 2019 17:24:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556040241; bh=iYPrKA+CLfE+81yGX8HKug1p2zjXsokfBC4B5o7cWfc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XXy3hiAAkeIWF29U1MFFQT+Kf4podYbKv3dMvIzY5Tn4Rc0LkcSl3npDijWPdNkrA x0splrtWA44skJGul3zEoJT7Nu/OBFWC6o8q2h2iKEfHpvnEu3BNedVoNqyQySFE+2 RfGOFajxsstuT3bSmQJ6g2DtIjvgu9ek+2hoKj9Q= Received: by mail-wm1-f42.google.com with SMTP id o25so1059095wmf.5 for ; Tue, 23 Apr 2019 10:24:00 -0700 (PDT) X-Gm-Message-State: APjAAAU1oIGcUgx9S4pbYlod7TvQmMvkgg0xkyPZGGUe8QcnfYVDjz3s lrgyqSfvv1nkokh4LyH/UOT79nz9uY6lnqhzXaKNVA== X-Received: by 2002:a1c:e188:: with SMTP id y130mr3031759wmg.83.1556040239484; Tue, 23 Apr 2019 10:23:59 -0700 (PDT) MIME-Version: 1.0 References: <20190423065706.15430-1-namit@vmware.com> <44A66873-0834-4794-81A5-3B2131314AA4@vmware.com> In-Reply-To: <44A66873-0834-4794-81A5-3B2131314AA4@vmware.com> From: Andy Lutomirski Date: Tue, 23 Apr 2019 10:23:47 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86/mm/tlb: Remove flush_tlb_info from the stack To: Nadav Amit Cc: Andy Lutomirski , Peter Zijlstra , Borislav Petkov , Ingo Molnar , Thomas Gleixner , X86 ML , LKML , Dave Hansen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 23, 2019 at 9:56 AM Nadav Amit wrote: > > > On Apr 23, 2019, at 9:50 AM, Andy Lutomirski wrote: > > > > On Tue, Apr 23, 2019 at 12:12 AM Nadav Amit wrote: >https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=3Dx8= 6/fixes >> Remove flush_tlb_info variables from the stack. This allows to a= lign > >> flush_tlb_info to cache-line and avoid potentially unnecessary cache > >> line movements. It also allows to have a fixed virtual-to-physical > >> translation of the variables, which reduces TLB misses. > >> > >> Use per-CPU struct for flush_tlb_mm_range() and > >> flush_tlb_kernel_range(). Add debug assertions to ensure there are > >> no nested TLB flushes that might overwrite the per-CPU data. For > >> arch_tlbbatch_flush(), use a const struct. > >> > >> Results when running a microbenchmarks that performs 10^6 MADV_DONTEED > >> operations and touching a page, in which 3 additional threads run a > >> busy-wait loop (5 runs): > > > > Can you add a memset(,,,. 0, sizeof(struct flush_tlb_info)) everywhere > > you grab it? Or, even better, perhaps do something like: > > > > static inline struct flush_tlb_info *get_flush_tlb_info(void) > > { > > /* check reentrancy, make sure that we use smp_processor_id() or > > otherwise assert that we're bound to a single CPU. */ > > struct flush_tlb_info *ptr =3D this_cpu_ptr(...); > > memset(ptr, 0, sizeof(*ptr)); > > return ptr; > > } > > > > static inline void put_flush_tlb_info(void) > > { > > /* finish checking reentrancy. */ > > } > > I=E2=80=99ll check if the compiler is smart enough to avoid redundant ass= ignments, > and if it is not, I=E2=80=99ll just give all the struct arguments to > get_flush_tlb_info() instead of memset() if you don=E2=80=99t mind. Sounds good. > > I also want to give a try for parallelizing the remote and local > invocations, which really annoys me every time I look at the code. Yes please!