Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1461imm; Tue, 31 Jul 2018 12:40:59 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcab8CkIMr6g9fR38c8Qr/VYVed34gwOObh9Pqmtvdyutc4Ok7R4TjiyOaErXcx6P+tycW5 X-Received: by 2002:a63:4e5f:: with SMTP id o31-v6mr22093925pgl.256.1533066059309; Tue, 31 Jul 2018 12:40:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533066059; cv=none; d=google.com; s=arc-20160816; b=co2TvcwajEknlwcpKXygMp1igJIUr69Oq5PWyuLDFMaHNvAHyugK2ck0SDfX2siPGV /tumgvBOwqjBx80VRd7g6QjGTVaW9sruouAWF8M0QrrSERE7MeTrtxR2TLXeVKbiC88o EdRi3bHrfVkqWSaazZt72npPWMe0wxHC1e2GEUzNhJI37KzfkW7VbPGXPnVjX+Qw3emk uRExAmK76HmM7UG148y9qMs//Kw+J4Rd498fwUqLsTyDymvCjp+C5HfyFX3baKBzk6SM 0jiVVDibFDqPmE9PFiizCIT2waYGcAe9cT2F7BqceycLBKttq+dldmmvlku/bjIuY7wb KnNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=uqrVYi9EeFnvrnxQY3HwSb1FaK8ZRIYKWRg2SPFlWek=; b=KTFuqHWPd+Yc46uNUV+cSs9RZic0uNYoYx6J6TBRzzvnODcEwKrRgDC9/Eix06a8ku q5G+WEhldrQu+PQinpON1KYYaNqLswYdLAh2TSGDjzLTnGpCpdnuIX5ISO5+adL9/GA3 QJxHNxi2EPGFhsXpSWMWW+SNhKV7wj8AqpjyqwvS0CFw62tg40otJ69LNxTbpE1E2A6Q MLir/AR88DscPGvzRYefyEVK1sPTkxoumUNQ+Elgco0TqNKmcAXT+UzMGsubRfOdL+YW T3pN59aRijm5DG+jHTPQKCcu61lSiPM1dC2JMkDfOfS+u+Pd3Fuzv4yN3kVvsKy79OGt /XhA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u19-v6si13588789pgk.100.2018.07.31.12.40.39; Tue, 31 Jul 2018 12:40:59 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732357AbeGaVUd (ORCPT + 99 others); Tue, 31 Jul 2018 17:20:33 -0400 Received: from mga06.intel.com ([134.134.136.31]:3846 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732282AbeGaVUd (ORCPT ); Tue, 31 Jul 2018 17:20:33 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2018 12:38:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,428,1526367600"; d="scan'208";a="77594078" Received: from rchatre-s.jf.intel.com ([10.54.70.76]) by orsmga001.jf.intel.com with ESMTP; 31 Jul 2018 12:38:43 -0700 From: Reinette Chatre To: tglx@linutronix.de, mingo@redhat.com, fenghua.yu@intel.com, tony.luck@intel.com, vikas.shivappa@linux.intel.com Cc: gavin.hindman@intel.com, jithu.joseph@intel.com, dave.hansen@intel.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org, Reinette Chatre Subject: [PATCH 0/2] x86/intel_rdt and perf/x86: Fix lack of coordination with perf Date: Tue, 31 Jul 2018 12:38:27 -0700 Message-Id: X-Mailer: git-send-email 2.17.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear Maintainers, The success of Cache Pseudo-Locking can be measured via the use of performance events. Specifically, the number of cache hits and misses reading a memory region after it has been pseudo-locked to cache. This measurement is triggered via the resctrl debugfs interface. To ensure most accurate results the performance counters and their configuration registers are accessed directly. This is currently done without coordination with other performance event users and will have consequences any time two users, for example perf and cache pseudo-locking, attempt to do any kind of measurement at the same time. The performance counter reservation mechanism for individual counters is available to cache pseudo-locking and could be used. That would require duplicating the currently private reservation mechanism for all counters. Instead in this work the reservation mechanism for all counters on the system is exposed and subsequently used by the cache pseudo-locking measurement code. Your feedback on this work will be greatly appreciated. Reinette Reinette Chatre (2): perf/x86: Expose PMC hardware reservation x86/intel_rdt: Coordinate performance monitoring with perf Documentation/x86/intel_rdt_ui.txt | 4 ---- arch/x86/events/core.c | 6 ++++-- arch/x86/kernel/cpu/intel_rdt.h | 2 ++ arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c | 8 ++++++++ 4 files changed, 14 insertions(+), 6 deletions(-) -- 2.17.0