Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp260910ybd; Tue, 25 Jun 2019 20:58:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqz4PWYr9jTZ/ST5ImnWEnbvLFoD+sKHppEmfSb999DE8PocwSK/V9U9Xed0aGSFFmA4Bj54 X-Received: by 2002:a17:90a:9289:: with SMTP id n9mr1886288pjo.35.1561521533506; Tue, 25 Jun 2019 20:58:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561521533; cv=none; d=google.com; s=arc-20160816; b=GKlv8qFVnlgmdXmnj80Y7JyH+Hjozs3swozbRQJPL0Qkg+jpDiLiW2pMjeq83QIfUw 4h9EM3rwfy4rr2023/AhvU6IQJG4cjRJUxWqhUNg3ivOGA0zodpKT+ScJcls8YAn8oai RhVYBwmjtGUfMq14ywhOwlj4w1050xKz8oUztuMVa3I+Sftzs11Al+imeUmaTXBXPZYB oS1lk//c1t4Z7KrbdsNH335iHKACEVfESuRF8vVnkCUJlANU6RSDay3MNjZmTLdQdaVS dYaCv/nVOjGAADiRdVrHEU1ZMV8Iuj41NIlt4ivpHlOlMkBY/rU1jGRT/Oalg/kxjhwT HMog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=k3QR04l91C6EQKBB5AZiVKloadi3Gtsj+D08nFtbXqk=; b=fmhjDppF2O4yrHIHDf/Wigv+YsR/9yJ6RJJAch1c9XDWkXHGCYcUh7WgPtukzqTcuv fgUQp5gxcKCRxdYRyr8ecZ2od8kbef5Y8e1DOnLti1/67slqPr3TdPGFTDvNjcdFEn/x 17fPX5/CPZBQHt1rHPNtXHhWHTtOywPQaKSTrNJiNbRURl1wmf+3Qcuecvct4PbwDpqP XDEVIqiCaO9EE1HlC0bSyzXfJyL58hcLSRvsukp8cJdZ2Ze2pj/JkpZmiUraW+4yH9SM 80GUxcUlJCfmi+3K85SiKU+UGAbQjXw4wtam7cQcWHqNDrFSySouwG/c9xV409K4PJLj ABSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="z9RMt+T/"; 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 z10si14565106pgv.233.2019.06.25.20.58.36; Tue, 25 Jun 2019 20:58:53 -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="z9RMt+T/"; 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 S1726818AbfFZD6J (ORCPT + 99 others); Tue, 25 Jun 2019 23:58:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:43696 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726620AbfFZD6I (ORCPT ); Tue, 25 Jun 2019 23:58:08 -0400 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 017E0208CB for ; Wed, 26 Jun 2019 03:58:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561521488; bh=avFzZ4O2c+/K29+kDv53q6xh6xHapF0kzXoy3BP0j54=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=z9RMt+T/gc0ZJyl8ZFG1PJLgqZxyyIgKqs/T3VSzIasR83pgQC5s3OFDqIT2S1dMk 8iCh8oB+uJK2IXVxjXGBM1rD8tnXhlaF170qAb9ImnvkSRTb0zM1NswqZb+UCD9/m0 sEe2COBWenM/+LWPhgRBiqS80tW7iPxyNIY6+Cys= Received: by mail-wm1-f44.google.com with SMTP id g135so531491wme.4 for ; Tue, 25 Jun 2019 20:58:07 -0700 (PDT) X-Gm-Message-State: APjAAAWTGEoZgcCgxWCjoZe7OLXnT5N2Ho4Ufglt5bRejuy6TCVYs0rS 8kRj73Zn7LY2Lo0l1tqHO36Ctt+zwMu5xRkUEeJxIg== X-Received: by 2002:a7b:c450:: with SMTP id l16mr879120wmi.0.1561521486613; Tue, 25 Jun 2019 20:58:06 -0700 (PDT) MIME-Version: 1.0 References: <20190613064813.8102-1-namit@vmware.com> <20190613064813.8102-9-namit@vmware.com> In-Reply-To: From: Andy Lutomirski Date: Tue, 25 Jun 2019 20:57:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 8/9] x86/tlb: Privatize cpu_tlbstate To: Dave Hansen Cc: Nadav Amit , Peter Zijlstra , Andy Lutomirski , LKML , Ingo Molnar , Borislav Petkov , X86 ML , Thomas Gleixner , Dave Hansen Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 25, 2019 at 2:52 PM Dave Hansen wrote: > > On 6/12/19 11:48 PM, Nadav Amit wrote: > > cpu_tlbstate is mostly private and only the variable is_lazy is shared. > > This causes some false-sharing when TLB flushes are performed. > > Presumably, all CPUs doing TLB flushes read 'is_lazy'. Because of this, > when we write to it we have to do the cache coherency dance to get rid > of all the CPUs that might have a read-only copy. > > I would have *thought* that we only do writes when we enter or exist > lazy mode. That's partially true. We do write in enter_lazy_tlb(), but > we also *unconditionally* write in switch_mm_irqs_off(). That seems > like it might be responsible for a chunk (or even a vast majority) of > the cacheline bounces. > > Is there anything preventing us from turning the switch_mm_irqs_off() > write into: > > if (was_lazy) > this_cpu_write(cpu_tlbstate.is_lazy, false); > > ? > > I think this patch is probably still a good general idea, but I just > wonder if reducing the writes is a better way to reduce bounces. Good catch! I'm usually pretty good about this for test_and_set()-style things, but I totally missed this obvious unnecessary write when I did this. I hereby apologize for all the cycles I wasted :) --Andy