Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp804749img; Mon, 18 Mar 2019 14:47:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqx5BML9rWZmdK4zs1VYmNzsV3ZwQUrr7zFjjYQ7kItrC0zRWX1wQoBkdtNM+uyrIYENCFBf X-Received: by 2002:a63:1156:: with SMTP id 22mr18984935pgr.357.1552945619944; Mon, 18 Mar 2019 14:46:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552945619; cv=none; d=google.com; s=arc-20160816; b=TWOVUSB3q7qWSLH3mxxOrtY2pEJBabC8uh2pjUUOpv97ZUa0Lrqs0W5SVrbK2hfPja hecMTS6oPo+fdRVFUWVztgJ7uqDWIGCLxHbMWBuUCLFiWn/mkiLLfq39vV9cId9Esk/C S41PiZHQlgxNBUdhsh4YDIaLIdG801bUQKMmd8Fx+vGxhqxcsNNxN6STTKICcMDLgroP anlB1+tb/awVq+YM0pXEDqWZ1E089Xk0RKu+/39cm/y/bqWcU/qLIJeUeyfPvDhsnPx3 dVfh7Dj7zrkSu8hTTi1ctVygtfemHP0XKoRdfK95nVHv0+bV8W2yq3hxpDNrq8tjAy3/ kiEg== 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; bh=EsHGz9m4m7tU1qrS6LF+7+eCIaa3E0jTtTu+Nay0UuM=; b=JrM0FoIpEVweGQcXDAwuEd1naLIBDV2blGbf2J/WO4IHTXGDfK5wJzB6HenaMHllTM EHl5GkDM27xxkEJG5NpWRJnt+zQggEmYu6oCO+aIKBWwSIpk3lPxD7wYmjoKLRINGM7Y BwhYwToSOcgR1wKtIHL3PicAnnGWgmVit5h4/LU/5wnt9V6goVXezsDilUZpNgaOgxYh gWABRe9mbbFX9jzj5Qvou5P1UBIMWVy4UbYW9fKymOyfcKs82XlZWRHaT9UTscUfmKD3 7VWIyRDsCFpt8dXS8PoPeoWtTfOf7wkp6YQTO/DTGpH7FZoZYdF8/MRoBcocEtXo7ZZf Fdbw== 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 x20si10229866plr.16.2019.03.18.14.46.45; Mon, 18 Mar 2019 14:46: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 S1727671AbfCRVoT (ORCPT + 99 others); Mon, 18 Mar 2019 17:44:19 -0400 Received: from mga04.intel.com ([192.55.52.120]:57594 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727515AbfCRVoQ (ORCPT ); Mon, 18 Mar 2019 17:44:16 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Mar 2019 14:44:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,495,1544515200"; d="scan'208";a="308301784" Received: from otc-icl-cdi187.jf.intel.com ([10.54.55.103]) by orsmga005.jf.intel.com with ESMTP; 18 Mar 2019 14:44:15 -0700 From: kan.liang@linux.intel.com To: peterz@infradead.org, acme@kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org Cc: tglx@linutronix.de, jolsa@kernel.org, eranian@google.com, alexander.shishkin@linux.intel.com, ak@linux.intel.com, Kan Liang Subject: [PATCH 04/22] perf/x86/lbr: Avoid reading the LBRs when adaptive PEBS handles them Date: Mon, 18 Mar 2019 14:41:26 -0700 Message-Id: <20190318214144.4639-5-kan.liang@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20190318214144.4639-1-kan.liang@linux.intel.com> References: <20190318214144.4639-1-kan.liang@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Andi Kleen With adaptive PEBS the CPU can directly supply the LBR information, so we don't need to read it again. But the LBRs still need to be enabled. Add a special count to the cpuc that distinguishes these two cases, and avoid reading the LBRs unnecessarily when PEBS is active. Signed-off-by: Andi Kleen Signed-off-by: Kan Liang --- arch/x86/events/intel/lbr.c | 13 ++++++++++++- arch/x86/events/perf_event.h | 1 + 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c index 58889f952959..b8cac31f089c 100644 --- a/arch/x86/events/intel/lbr.c +++ b/arch/x86/events/intel/lbr.c @@ -488,6 +488,8 @@ void intel_pmu_lbr_add(struct perf_event *event) * be 'new'. Conversely, a new event can get installed through the * context switch path for the first time. */ + if (x86_pmu.intel_cap.pebs_baseline && event->attr.precise_ip > 0) + cpuc->lbr_pebs_users++; perf_sched_cb_inc(event->ctx->pmu); if (!cpuc->lbr_users++ && !event->total_time_running) intel_pmu_lbr_reset(); @@ -507,8 +509,11 @@ void intel_pmu_lbr_del(struct perf_event *event) task_ctx->lbr_callstack_users--; } + if (x86_pmu.intel_cap.pebs_baseline && event->attr.precise_ip > 0) + cpuc->lbr_pebs_users--; cpuc->lbr_users--; WARN_ON_ONCE(cpuc->lbr_users < 0); + WARN_ON_ONCE(cpuc->lbr_pebs_users < 0); perf_sched_cb_dec(event->ctx->pmu); } @@ -658,7 +663,13 @@ void intel_pmu_lbr_read(void) { struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events); - if (!cpuc->lbr_users) + /* + * Don't read when all LBRs users are using adaptive PEBS. + * + * This could be smarter and actually check the event, + * but this simple approach seems to work for now. + */ + if (!cpuc->lbr_users || cpuc->lbr_users == cpuc->lbr_pebs_users) return; if (x86_pmu.intel_cap.lbr_format == LBR_FORMAT_32) diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h index db3b622265fa..27c7945b5174 100644 --- a/arch/x86/events/perf_event.h +++ b/arch/x86/events/perf_event.h @@ -216,6 +216,7 @@ struct cpu_hw_events { * Intel LBR bits */ int lbr_users; + int lbr_pebs_users; struct perf_branch_stack lbr_stack; struct perf_branch_entry lbr_entries[MAX_LBR_ENTRIES]; struct er_account *lbr_sel; -- 2.17.1