Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp3969901pxb; Mon, 30 Aug 2021 15:09:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxlXMh4H4/RrB+7XKLDO2eoYtmXPHZTlLwsvsXz68FLQ3rzLQ01AJvxsVxLheWo0EKCp3Ed X-Received: by 2002:a05:6402:354d:: with SMTP id f13mr26087032edd.382.1630361369106; Mon, 30 Aug 2021 15:09:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630361369; cv=none; d=google.com; s=arc-20160816; b=vUfEac9QN1kmYioFYA3DTlrp7Y+mwRiXGMWOkla1iCtd9PeYJOuLY6+4ItTpJuKuUL Eft/7qpOR+7GGLpW3hN/gv4eRJH9kTvm+zctIo9FwwQvkWXHMwHBzt4+i0CKbDulxMgx rqn3cvg0Sphzh1vI+kRkVxrhvZcLqKviZu0eeQcMobzLRu1cMKSpRjc1CUwHfom7dzR6 4Y3jWlP/yCV8LB7chcF9ZU+opreorSdBJJ7TkByj5ZTqUVLuoayzy5YPEqYNf+IIgsdW PAv9DGTPoRb4bdBarR7sQ/aXzFOIPGqDbht4dgpG19lFDoiZSoy9C/y38h/FvSH/4bJ4 Z7NQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=3AI5mZl+BbVjezvyWOJjh9FI+0uPl+5gVobqJ+UruaM=; b=GqYCJy2FD2GgBlXRIsc/6Ty+o+J1EAw8S6LIVlx2c9+AUkXTMvSPs/s7FP5Gttz1wA 6MsjSTcwvvtb7qJ5hQQfdKvlilr1MzqSlUVWQ9GY24cqGMc3APbzw5ElmTd1z0Lv9d46 XDwgJT7IVKxFcsmZhd9obamVo14cz7oEARvfW4y5fYxhk8TFRtqAXncL5L61Ub0cWwD2 7HRKJdIfKrGrJrsgm1qGT+hAHHz6tABw9MfTHIwBeGc9pxjLaDCbiiyTHGnR2DGOo+Oq pwRnhTwMAXfjc6OJ4kOaukRf/7eFNpLbVDn9AOn6b/pr6lAi6aj3V65AJ7SWnsi0toit DwUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YmxO9Acp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cq26si12075885edb.411.2021.08.30.15.09.03; Mon, 30 Aug 2021 15:09:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YmxO9Acp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237832AbhH3WGb (ORCPT + 99 others); Mon, 30 Aug 2021 18:06:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229887AbhH3WGb (ORCPT ); Mon, 30 Aug 2021 18:06:31 -0400 Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D30DC061575; Mon, 30 Aug 2021 15:05:37 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id z18so31058882ybg.8; Mon, 30 Aug 2021 15:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3AI5mZl+BbVjezvyWOJjh9FI+0uPl+5gVobqJ+UruaM=; b=YmxO9Acp8m7p1yf7GZsf4g+mJLtokK7wrLGrs8UtWUDUD1WjknuD0P/x/hKGhseJoy qbl287mM2JhIDrCOAdN8CXUOwBJ4/YPzROOF4YbeuJJ21YIaU+r/aeGzpR+mwDibj9VZ vnIaRD1zlLWUThIXRpeWeAIF/rwCjLQ7eAXxdQQNZNsx+r3sJFnqpk4BEYFAPRf9amME stOGvWfR9ss/XXK7J/4gnLjhKE4nULVcu8PV8UVJOIcxJvtXb8fL+j+tD8NiY3e5Q0av Fz9ISGG9SxxT+EJqKwJkE1bd9Bd+k49S/tnaA03UAqhvKY2FhpgqJJAn7B0MQd0ppuEE 3eSQ== 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=3AI5mZl+BbVjezvyWOJjh9FI+0uPl+5gVobqJ+UruaM=; b=ZUtzwYq2FKvlC7yHyC98Iqb0UwX6jdgC5E+6qLUAUUT3S8gGygqE6Xm/ZkpoIBCSud gE7T7CDR9iUmvAD2qje3HPDRICjs8jOi0d4Xeu1RqB64KVuZmYCpuEh7xtxJTxG8OP68 RT+re6Io+C9mjoFoK2M18yLriMqlwRA72TxvkoURpGmj5lzU1MXAuuUsL6K4H3AuzIGT hMadAhDwhoqO4M2aSoSKUDJHGMdQAXKn8uYU5TCWuuFy3Jec8zOThJG9Vok8pxjUpmDG UcGs6e5fMBNBmG89yG9ViRzDQe0oTn9P6ZBAeL3wDWT8AsZZbdpyaQk5gGk0ocUgk5IW BPew== X-Gm-Message-State: AOAM5307YhTROHrE931tEYioqJwKECWPVDbQBg/l9kyWFU1By4NfIJgj uHsEOMivBYPPxCcAiKITTqamZfPCNjKV6GRhR5c= X-Received: by 2002:a25:ac7:: with SMTP id 190mr25051248ybk.260.1630361136478; Mon, 30 Aug 2021 15:05:36 -0700 (PDT) MIME-Version: 1.0 References: <20210830214106.4142056-1-songliubraving@fb.com> <20210830214106.4142056-2-songliubraving@fb.com> In-Reply-To: <20210830214106.4142056-2-songliubraving@fb.com> From: Andrii Nakryiko Date: Mon, 30 Aug 2021 15:05:25 -0700 Message-ID: Subject: Re: [PATCH v3 bpf-next 1/3] perf: enable branch record for software events To: Song Liu Cc: bpf , open list , Arnaldo Carvalho de Melo , Peter Ziljstra , Ingo Molnar , Kajol Jain , Kernel Team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 30, 2021 at 2:42 PM Song Liu wrote: > > The typical way to access branch record (e.g. Intel LBR) is via hardware > perf_event. For CPUs with FREEZE_LBRS_ON_PMI support, PMI could capture > reliable LBR. On the other hand, LBR could also be useful in non-PMI > scenario. For example, in kretprobe or bpf fexit program, LBR could > provide a lot of information on what happened with the function. Add API > to use branch record for software use. > > Note that, when the software event triggers, it is necessary to stop the > branch record hardware asap. Therefore, static_call is used to remove some > branch instructions in this process. > > Signed-off-by: Song Liu > --- > arch/x86/events/intel/core.c | 24 ++++++++++++++++++++++-- > include/linux/perf_event.h | 24 ++++++++++++++++++++++++ > kernel/events/core.c | 3 +++ > 3 files changed, 49 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c > index ac6fd2dabf6a2..d28d0e12c112c 100644 > --- a/arch/x86/events/intel/core.c > +++ b/arch/x86/events/intel/core.c > @@ -2155,9 +2155,9 @@ static void __intel_pmu_disable_all(void) > > static void intel_pmu_disable_all(void) > { > + intel_pmu_lbr_disable_all(); > __intel_pmu_disable_all(); > intel_pmu_pebs_disable_all(); > - intel_pmu_lbr_disable_all(); > } > > static void __intel_pmu_enable_all(int added, bool pmi) > @@ -2186,6 +2186,20 @@ static void intel_pmu_enable_all(int added) > __intel_pmu_enable_all(added, false); > } > > +static int > +intel_pmu_snapshot_branch_stack(struct perf_branch_snapshot *br_snapshot) > +{ > + struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events); > + > + intel_pmu_disable_all(); > + intel_pmu_lbr_read(); > + memcpy(br_snapshot->entries, cpuc->lbr_entries, > + sizeof(struct perf_branch_entry) * x86_pmu.lbr_nr); > + br_snapshot->nr = x86_pmu.lbr_nr; > + intel_pmu_enable_all(0); > + return 0; > +} > + > /* > * Workaround for: > * Intel Errata AAK100 (model 26) > @@ -6283,9 +6297,15 @@ __init int intel_pmu_init(void) > x86_pmu.lbr_nr = 0; > } > > - if (x86_pmu.lbr_nr) > + if (x86_pmu.lbr_nr) { > pr_cont("%d-deep LBR, ", x86_pmu.lbr_nr); > > + /* only support branch_stack snapshot for perfmon >= v2 */ > + if (x86_pmu.disable_all == intel_pmu_disable_all) > + static_call_update(perf_snapshot_branch_stack, > + intel_pmu_snapshot_branch_stack); > + } > + > intel_pmu_check_extra_regs(x86_pmu.extra_regs); > > /* Support full width counters using alternative MSR range */ > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h > index fe156a8170aa3..1f42e91668024 100644 > --- a/include/linux/perf_event.h > +++ b/include/linux/perf_event.h > @@ -57,6 +57,7 @@ struct perf_guest_info_callbacks { > #include > #include > #include > +#include > #include > > struct perf_callchain_entry { > @@ -1612,4 +1613,27 @@ extern void __weak arch_perf_update_userpage(struct perf_event *event, > extern __weak u64 arch_perf_get_page_size(struct mm_struct *mm, unsigned long addr); > #endif > > +/* > + * Snapshot branch stack on software events. > + * > + * Branch stack can be very useful in understanding software events. For > + * example, when a long function, e.g. sys_perf_event_open, returns an > + * errno, it is not obvious why the function failed. Branch stack could > + * provide very helpful information in this type of scenarios. > + * > + * On software event, it is necessary to stop the hardware branch recorder > + * fast. Otherwise, the hardware register/buffer will be flushed with > + * entries af the triggering event. Therefore, static call is used to > + * stop the hardware recorder. > + */ > +#define MAX_BRANCH_SNAPSHOT 32 Can you please make it an enum instead? It will make this available as a constant in vmlinux.h nicely, without users having to #define it every time. > + > +struct perf_branch_snapshot { > + unsigned int nr; > + struct perf_branch_entry entries[MAX_BRANCH_SNAPSHOT]; > +}; > + > +typedef int (perf_snapshot_branch_stack_t)(struct perf_branch_snapshot *); > +DECLARE_STATIC_CALL(perf_snapshot_branch_stack, perf_snapshot_branch_stack_t); > + > #endif /* _LINUX_PERF_EVENT_H */ > diff --git a/kernel/events/core.c b/kernel/events/core.c > index 011cc5069b7ba..22807864e913b 100644 > --- a/kernel/events/core.c > +++ b/kernel/events/core.c > @@ -13437,3 +13437,6 @@ struct cgroup_subsys perf_event_cgrp_subsys = { > .threaded = true, > }; > #endif /* CONFIG_CGROUP_PERF */ > + > +DEFINE_STATIC_CALL_RET0(perf_snapshot_branch_stack, > + perf_snapshot_branch_stack_t); > -- > 2.30.2 >