Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp1588437img; Tue, 19 Mar 2019 10:53:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqybyuiKwZmS36Ug73nTnKBLRpvGKuMhde12Cd+5ACcnd3wCCn1ECl6dAAwtNNggNlFYGG9B X-Received: by 2002:a17:902:aa87:: with SMTP id d7mr25985484plr.146.1553017999836; Tue, 19 Mar 2019 10:53:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553017999; cv=none; d=google.com; s=arc-20160816; b=czKKc4nCB7e9jD66pmmng8btcw/cffuJKzC80KLON+GyZZYf80D2YcAcyXdkBxjfBM +Low3WTAfrSdeoTDYiopLsJhTYS59QhDfjRkolQ4QSEJlFzwbbPwBwiChgRcYeQLcVqB iaMdjj5yto5d9Uq/6JDyy0u6mA9xsjldPOdUvk6CqNDB82npVgQo/mmc1LpalGxnGqTr nTLAojMKR+z869474Utrc4VjFkmvUa64MCjIikV2YNBUTOjr+VwoWTdStXgNfRZAZivU U6HlVlJpjtyzgsHfKHCZqEQttGDuahagHHh0WmPj7GBFs0QPDA8S5v8ObGoECqzOaS43 zr7Q== 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=Ujmk147faWtjPzsKh7iCqt+9xCD/NBZvc9Bqu3/KOQ8=; b=raen2Vv/mHMJSYMIyiZmSB+FnIHAFIio6UFcyKpTpoG5+QMn3twzJcy/R8ZmWuMFvI 3WNhXtUYgpYteDcNkXBZIgbx0ZZGn+PS1hMr4XwuUnt2/sgrCz0RXHjxEDA0qcy7AAgX sDnz6Qva3wHhT/Mzsws5XrRAdtimDCHX7cO5GVJMMNFxYbTNqt8XJl7450ZgD31l33Bt 5Clq8kEbSDfbXazSO/mPs2G3JSAVt8n8Qcf0pr+1eV2CPpf//QqqKJP9HfvObornD2Mw TPyTf7PbaPv+YCM97PTfbSDanAB3QHaQD4Oy4Easb58RASiqwmMrJgSeW4kRzOqbDOeI OORg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=JNJCga+i; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t32si6192622pgl.7.2019.03.19.10.53.04; Tue, 19 Mar 2019 10:53:19 -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=@google.com header.s=20161025 header.b=JNJCga+i; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727520AbfCSRwP (ORCPT + 99 others); Tue, 19 Mar 2019 13:52:15 -0400 Received: from mail-vs1-f65.google.com ([209.85.217.65]:33669 "EHLO mail-vs1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727189AbfCSRwP (ORCPT ); Tue, 19 Mar 2019 13:52:15 -0400 Received: by mail-vs1-f65.google.com with SMTP id z6so12263694vsc.0 for ; Tue, 19 Mar 2019 10:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ujmk147faWtjPzsKh7iCqt+9xCD/NBZvc9Bqu3/KOQ8=; b=JNJCga+ijl20TUPqrF5QLh9DhZZlB8zlL5q0LjqGEJtjZA/Pkh4D6v/8XVzSycXJ5O +lYrmdUo6HYanvf2N20ujXL10j49dDAdCzCttzhFKcHmLOVW1rOP1pqjSLVkFZAE25Ey xdSoXuKG8MQ41nVa8HC+7kT9pBa56B4bh34yqVydae8WxVYUlq85LEWrYuHqsv2N2TMs THGA2CgV1qHQnX0bqeLHa2can9OHSTjNRN87H2GlXR8ptsId09MyQs4lUH8Fj7J5HFLL EZXZ7U0HS55xCDWXT6o2wuqRXZDY+7YZUiGv5zcFQxSsygS94+w7ORUklABpsKJEn7Rb z9xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ujmk147faWtjPzsKh7iCqt+9xCD/NBZvc9Bqu3/KOQ8=; b=uZ5emIHBZ/t5y9b+NuyRh1EZwmbUD3qPYnLGGmHUL6iJShqQuVdRd2eF0dtYdAr28c QIbxL4TYuKOR+azMk9JqTt4+CIilZOPal5R08YsC6VqYb/rXMOWGsmjluL3adG5ehSQa 533ssWzPnRydIN1c7fmg0dM6WXspftE/ijEBgIMPf1taJD2/n3xs08kCPf3u3s6AAgE5 VorsarHJwfwRMDvSJVhKmxLTp4XVju9uc339zy3CbV7QTuSQq7oxqMjYDcM7Dl+Oculk UDCs23h7VjdDnymVc4gjDcs6x158he16X3WZmoOguolXGArMIrqbyH8vLGdWtLqCxS8p 2ZcQ== X-Gm-Message-State: APjAAAVbFBccmSZRpCnTxyWvn8GMo6B/SqKRUXJJbiHy3qzDbR3OmYZa B8hAN6TXjxtXYVn12Q2fgQ8pGPesAknEr3hqy02V8A== X-Received: by 2002:a67:ff07:: with SMTP id v7mr2176894vsp.231.1553017933859; Tue, 19 Mar 2019 10:52:13 -0700 (PDT) MIME-Version: 1.0 References: <20190314130113.919278615@infradead.org> <20190314130705.441549378@infradead.org> <20190319110549.GC5996@hirez.programming.kicks-ass.net> In-Reply-To: <20190319110549.GC5996@hirez.programming.kicks-ass.net> From: Stephane Eranian Date: Tue, 19 Mar 2019 10:52:01 -0700 Message-ID: Subject: Re: [PATCH 1/8] perf/x86/intel: Fix memory corruption To: Peter Zijlstra Cc: Ingo Molnar , Jiri Olsa , LKML , tonyj@suse.com, nelson.dsouza@intel.com 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, Mar 19, 2019 at 4:05 AM Peter Zijlstra wrote: > > On Mon, Mar 18, 2019 at 11:29:25PM -0700, Stephane Eranian wrote: > > > > --- a/arch/x86/events/intel/core.c > > > +++ b/arch/x86/events/intel/core.c > > > @@ -3410,7 +3410,7 @@ tfa_get_event_constraints(struct cpu_hw_ > > > /* > > > * Without TFA we must not use PMC3. > > > */ > > > - if (!allow_tsx_force_abort && test_bit(3, c->idxmsk)) { > > > + if (!allow_tsx_force_abort && test_bit(3, c->idxmsk) && idx >= 0) { > > > c = dyn_constraint(cpuc, c, idx); > > > c->idxmsk64 &= ~(1ULL << 3); > > > c->weight--; > > > > > > > > > I was not cc'd on the patch that added allow_tsx_force_abort, so I > > Yeah, that never was public :-( I didn't particularly like that, but > that's the way it is. > > > will give some comments here. > > > If I understand the goal of the control parameter it is to turn on/off > > the TFA workaround and thus determine whether or not PMC3 is > > available. I don't know why you would need to make this a runtime > > tunable. > > Not quite; the control on its own doesn't directly write the MSR. And > even when the work-around is allowed, we'll not set the MSR unless there > is also demand for PMC3. > Trying to understand this better here. When the workaround is enabled (tfa=0), you lose PMC3 and transactions operate normally. When it is disabled (tfa=1), transactions are all aborted and PMC3 is available. If you are saying that when there is a PMU event requesting PMC3, then you need PMC3 avail, so you set the MSR so that tfa=1 forcing all transactions to abort. But in that case, you are modifying the execution of the workload when you are monitoring it, assuming it uses TSX. You want lowest overhead and no modifications to how the workload operates, otherwise how representative is the data you are collecting? I understand that there is no impact on apps not using TSX, well, except on context switch where you have to toggle that MSR. But for workloads using TSX, there is potentially an impact. > It is a runtime tunable because boot parameters suck. > > > That seems a bit dodgy. But given the code you have here right now, we > > have to deal with it. A sysadmin could flip the control at any time, > > including when PMC3 is already in used by some events. I do not see > > the code that schedules out all the events on all CPUs once PMC3 > > becomes unavailable. You cannot just rely on the next context-switch > > or timer tick for multiplexing. > > Yeah, meh. You're admin, you can 'fix' it. In practise I don't expect > most people to care about the knob, and the few people that do, should > be able to make it work. I don't understand how this can work reliably. You have a knob to toggle that MSR. Then, you have another one inside perf_events and then the sysadmin has to make sure nobody (incl. NMI watchdog) is using the PMU when this all happens. How can this be a practical solution? Am I missing something here?