Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2023381ybl; Sat, 25 Jan 2020 14:33:06 -0800 (PST) X-Google-Smtp-Source: APXvYqzIvNx1tOnZutbCnnFvB6YBmMQJyvSsVHdWypGK6WaJh0EWdPgVuYMdfndBpQUBY0eyqVCD X-Received: by 2002:a9d:6e82:: with SMTP id a2mr7362080otr.336.1579991586218; Sat, 25 Jan 2020 14:33:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579991586; cv=none; d=google.com; s=arc-20160816; b=UnDb71JkYzOzz1YqjjoxbC9QJCJ9nAN6e7Fyll0vP/NwRikEBOq/0t80IpmaPZPZKb uWJzTKWKTWCz5meWFuZWF2EsZBWz6H7Hoqz8rGndwl9wklqXfU6ScscLy2aPjX4/uLW7 QioMQJVCYGJHVN49eATeOACcxbDijmxb7P8nwFCJHlf4jnwPrfZINvwzef2w+DwSAW+a cYxvELI9KlDB4UYwgx8Egdi5xPfKUR4OUdQM7WHs7BdiHvztKF0Lg238sEqCpf8WxOUT FOQoS73jG2b1tWLmf1pbVOncq+phDYFp9UA8GXXN7P2dhrhhl8RF5f6RLl1yX/1Hot+o LbOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature:dkim-signature; bh=edZb6HITt6UVr7I2c+OC+aO2ZrbIvBHqXyYPhj4LQBA=; b=u8h5eE3/4wrMIGN+m/BopqXwu7Ipvt8tNnJVPDbE92TvtKLbO2bl/APiVS9kWaHEEJ sPOrzJr5zHTfVkB83L6NgqIOb/FwjsmAynvbwCJfXS30l2qg7HejtMfEoy+tMNo4FbED ipU89inMy2ARF1hXOFVJ6SW9I3p1ko14Ha6LMW/hd51Xd0/uqB7qigB6sHDPSltWjhp8 3J2thhQ2HOC9Hvram0N1JaR5F0QC4+SyKX+3h/V5sZZ8yecAUIZn6FlBlQtRDmzAr87v hpTTgDXdfh40ZHmHCulRxKWJGLvkzpZpr2BRnQBIngoHRfEJbRtGgcNSGsS5clk4BPjF 8hnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dxuuu.xyz header.s=fm2 header.b=my3L4jdg; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=gPOacjv6; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b11si1792620oie.152.2020.01.25.14.32.55; Sat, 25 Jan 2020 14:33:06 -0800 (PST) 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=@dxuuu.xyz header.s=fm2 header.b=my3L4jdg; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=gPOacjv6; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727747AbgAYWbh (ORCPT + 99 others); Sat, 25 Jan 2020 17:31:37 -0500 Received: from wnew2-smtp.messagingengine.com ([64.147.123.27]:44603 "EHLO wnew2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727250AbgAYWbh (ORCPT ); Sat, 25 Jan 2020 17:31:37 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.west.internal (Postfix) with ESMTP id 509203C5; Sat, 25 Jan 2020 17:31:35 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 25 Jan 2020 17:31:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dxuuu.xyz; h= from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; s=fm2; bh=edZb6HITt6UVr7I2c+OC+aO2Zr bIvBHqXyYPhj4LQBA=; b=my3L4jdgk6Hl3D7In3J0I2kHX6jwtxFEqZLxGRHHDy WUQnlLKXla97sggu0RljKOEGqgtfLziX18B3L1wuG096HlupVUiJrQ+962z4OSKP kuThRhY3XhWmWiCq0P35LaHMtC8abCyM+9xvYnThJTNOo76LermpopmfI+w+62Se 97B8R83UfUQ/Q1IxLlCygFFjvYl6Y+cyZ5wo14NcmYXuIb3zv2MsCQurpnochjBo XvZNJ7z95xsBIZffcZ7ykv3R124NcweXUSMO/YYQhrVKBR47YiJ+8YYowa5MafEs X8GyKntIOBUNKJPM98IptfpCwUDFkvpA63CdgaE1my9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :message-id:mime-version:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=edZb6HITt6UVr7I2c +OC+aO2ZrbIvBHqXyYPhj4LQBA=; b=gPOacjv6hIYa/F6QNNnY21LO5sux3ktI4 vdiUPtqjV+n2zvr41tTUDRs39hM3rCz04mahW3cBr8zhfARMUZDPi8pxj0o2uKrj n22yLZNSwEPDoJYk9eLcWGwbPzERWsuEd2LJ1vtBOFJKx0JgYJUhszJzE17BWHBN i3h2fwEriBFPHhShbmfolZvJDXVAhdd/80Asg5kFmu+Kpp70Bq/9imNdk03I2XcA j3kylFrHDG1sRGLTiQ146/KTHZZLNecip7c9TusIL1zH/s2Orkw0ECEcOC3Qd0B0 mnVG8zo3GEUPijBsWhH3fW9bu/tM1JBce6Xj7kPZt3wu6w2kSxs7A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrvdekgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecufghrlhcuvffnffculdejtddmnecujfgurhephffvuf ffkffoggfgsedtkeertdertddtnecuhfhrohhmpeffrghnihgvlhcuighuuceougiguhes ugiguhhuuhdrgiihiieqnecukfhppeduleelrddvtddurdeigedrfeenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegugihusegugihuuhhurdig hiii X-ME-Proxy: Received: from dlxu-fedora-R90QNFJV.thefacebook.com (prn-fbagreements-ext.thefacebook.com [199.201.64.3]) by mail.messagingengine.com (Postfix) with ESMTPA id 0F94A328005A; Sat, 25 Jan 2020 17:31:31 -0500 (EST) From: Daniel Xu To: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, songliubraving@fb.com, yhs@fb.com, andriin@fb.com Cc: Daniel Xu , linux-kernel@vger.kernel.org, kernel-team@fb.com, peterz@infradead.org, mingo@redhat.com, acme@kernel.org Subject: [PATCH v5 bpf-next 0/2] Add bpf_read_branch_records() helper Date: Sat, 25 Jan 2020 14:31:15 -0800 Message-Id: <20200125223117.20813-1-dxu@dxuuu.xyz> X-Mailer: git-send-email 2.21.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Branch records are a CPU feature that can be configured to record certain branches that are taken during code execution. This data is particularly interesting for profile guided optimizations. perf has had branch record support for a while but the data collection can be a bit coarse grained. We (Facebook) have seen in experiments that associating metadata with branch records can improve results (after postprocessing). We generally use bpf_probe_read_*() to get metadata out of userspace. That's why bpf support for branch records is useful. Aside from this particular use case, having branch data available to bpf progs can be useful to get stack traces out of userspace applications that omit frame pointers. Changes in v5: - Rename bpf_perf_prog_read_branches() -> bpf_read_branch_records() - Rename BPF_F_GET_BR_SIZE -> BPF_F_GET_BRANCH_RECORDS_SIZE - Squash tools/ bpf.h sync into selftest commit Changes in v4: - Add BPF_F_GET_BR_SIZE flag - Return -ENOENT on unsupported architectures - Only accept initialized memory in helper - Check buffer size is multiple of sizeof(struct perf_branch_entry) - Use bpf skeleton in selftest - Add commit messages - Spelling and formatting Changes in v3: - Document filling unused buffer with zero - Formatting fixes - Rebase Changes in v2: - Change to a bpf helper instead of context access - Avoid mentioning Intel specific things Daniel Xu (2): bpf: Add bpf_read_branch_records() helper selftests/bpf: add bpf_read_branch_records() selftest include/uapi/linux/bpf.h | 25 +++- kernel/trace/bpf_trace.c | 41 +++++++ tools/include/uapi/linux/bpf.h | 25 +++- .../selftests/bpf/prog_tests/perf_branches.c | 112 ++++++++++++++++++ .../selftests/bpf/progs/test_perf_branches.c | 74 ++++++++++++ 5 files changed, 275 insertions(+), 2 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/perf_branches.c create mode 100644 tools/testing/selftests/bpf/progs/test_perf_branches.c -- 2.21.1