Received: by 2002:a05:6500:1b8f:b0:1fa:5c73:8e2d with SMTP id df15csp1182052lqb; Thu, 30 May 2024 02:47:50 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVd7+WKJAVOr/eXEeygelZ4o8W7l9zq3vgEnZ2/A9Lbuq6FiC3/mhtCE+TpPPDsiA51+LPE7LDtDo/SfFcrEA32mVKdFMyKgBJHlSZn0Q== X-Google-Smtp-Source: AGHT+IEUF+V51fjb0epEjcZA+7b81CeIvt3bZnMuWHd+t2pEKphjLXheupEpBEsr5RsJYpLWX8GP X-Received: by 2002:a92:ca09:0:b0:374:5f1b:1133 with SMTP id e9e14a558f8ab-3747df4f039mr16286065ab.5.1717062469898; Thu, 30 May 2024 02:47:49 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1717062469; cv=pass; d=google.com; s=arc-20160816; b=th1j4lElsFjXn/P7eovW7/VnK5KNJlaYzK9FyLz4q8jlBnapTO1liPrjMm/vX0h7z9 3mABXyD2nmoc1efLqfefwva0D6SulbDWYw5q0E4mlvlqIgY4qNHSrY4eIgAsT9vAmT4I TGtQY4HJ8PVas3CpxHEVNxwzZVAWEIb+fTf20J+WvwIRc4F8gWZs7rmp5enBQHIAkx14 JxtTgrGj5UIl/0gGauGu0Z66L3MmJT/5HOBdC92uYW85n0Zrpez0qivvQki2mzW+NU0I IlYiPk7Vd/LdVRjUFYYhOJ3dLxfsxnKNec0mtFgEdHwG3f2QazceaT/ssKW2j/4x+zog VIMw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=+Nq7AAR6dRkqnFzkxJJa/ChgoUcodznvS7O95JqM2hU=; fh=kft6gKQW2r7QBfAoFs0fqT0jxTJwav0NQiaT+bjmVPA=; b=eNFSejjHvia0Q718LnjGdwF1C0PdPeEnNUEzzm/NJWVGpf6Lxsixn3D5kbhNaa0Md9 O8cgLZzl536uPqSQcJGsArfdZ3NKV25pQZPmOVJvY+7WmDLuOp7FkaHS1giEChH55cy9 pAtjP2JPRLe81/RnbDkKUFNcEUV1NAzXmyORnX/yqO6EnncKWJBnLGd9u5b+uocL6Fu0 Pgcoy8Dzt7Y7BgASO1iogLJW3Czek9MHN0QRMvaxiBeU7OmUmO6CSP6piBuNpjzEUpjm jGuay57nCLyiKjho1fazbEwtGWjV+l900MJG572EbOLwmPWi5zqBxPrKxcNmOKfTfPhE izsQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-195212-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-195212-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id 41be03b00d2f7-6bc32bd002csi2355625a12.608.2024.05.30.02.47.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 May 2024 02:47:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-195212-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-195212-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-195212-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 0882A281C63 for ; Thu, 30 May 2024 09:47:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A728C15444F; Thu, 30 May 2024 09:47:43 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7BFBF18396D; Thu, 30 May 2024 09:47:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717062463; cv=none; b=A8TLRE4TJt1N0kL5rpfjy6sn6hKpYsP5Qa9yXG3iaO91gwdGTVYNeP/M+wnnO4M21KAU8g8xdTyW+2wvliy8WvXfJUA34CXUINuMi1QfCmtILqrWs/HJfu7rGlF54Lc6rY2/MyaLHzbIdvWA2pZtkJK+eSxp7jxZgPjWF+waYKY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717062463; c=relaxed/simple; bh=oJceATgDva1QgjQ+6MSy7M5QY7VdjFO8E11FvM9DfH4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KLMgoVhyBtQ2T7E3/dtog0mWMICP7epfPCwSVyOwuuRnmVlGlynw5ZmJ4q+tvmpDVErJTKxS2rt3IQQCTZRfh5VTG+NchFOeUHdU6HO8q32AeJ+08eBxOi4KZC/433QXa4dIQ0zHeK4sQJ4in08BlkxvAmc2zz52/o+FgBygMp8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3C1B9339; Thu, 30 May 2024 02:47:58 -0700 (PDT) Received: from [192.168.1.100] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4A4AD3F641; Thu, 30 May 2024 02:47:32 -0700 (PDT) Message-ID: <80d33844-bdd2-4fee-81dd-9cd37c63d42c@arm.com> Date: Thu, 30 May 2024 10:47:34 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V17 0/9] arm64/perf: Enable branch stack sampling To: Anshuman Khandual , mark.rutland@arm.com Cc: Mark Brown , Rob Herring , Marc Zyngier , Suzuki Poulose , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com References: <20240405024639.1179064-1-anshuman.khandual@arm.com> Content-Language: en-US From: James Clark In-Reply-To: <20240405024639.1179064-1-anshuman.khandual@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05/04/2024 03:46, Anshuman Khandual wrote: > This series enables perf branch stack sampling support on arm64 platform > via a new arch feature called Branch Record Buffer Extension (BRBE). All > the relevant register definitions could be accessed here. > > https://developer.arm.com/documentation/ddi0601/2021-12/AArch64-Registers > > This series applies on 6.9-rc2. > > Also this series is being hosted below for quick access, review and test. > > https://git.gitlab.arm.com/linux-arm/linux-anshuman.git (brbe_v17) > > There are still some open questions regarding handling multiple perf events > with different privilege branch filters getting on the same PMU, supporting > guest branch stack tracing from the host etc. Finally also looking for some > suggestions regarding supporting BRBE inside the guest. The series has been > re-organized completely as suggested earlier. > > - Anshuman > [...] > > ------------------ Possible 'branch_sample_type' Mismatch ----------------- > > Branch stack sampling attributes 'event->attr.branch_sample_type' generally > remain the same for all the events during a perf record session. > > $perf record -e -e -j [workload] > > event_1->attr.branch_sample_type == event_2->attr.branch_sample_type > > This 'branch_sample_type' is used to configure the BRBE hardware, when both > events i.e and get scheduled on a given PMU. But during > PMU HW event's privilege filter inheritance, 'branch_sample_type' does not > remain the same for all events. Let's consider the following example > > $perf record -e cycles:u -e instructions:k -j any,save_type ls > > cycles->attr.branch_sample_type != instructions->attr.branch_sample_type > > Because cycles event inherits PERF_SAMPLE_BRANCH_USER and instruction event > inherits PERF_SAMPLE_BRANCH_KERNEL. The proposed solution here configures > BRBE hardware with 'branch_sample_type' from last event to be added in the > PMU and hence captured branch records only get passed on to matching events > during a PMU interrupt. > Hi Anshuman, Surely because of this example we should merge? At least we have to try to make the most common basic command lines work. Unless we expect all tools to know whether the branch buffer is shared between PMUs on each architecture or not. The driver knows though, so can merge the settings because it all has to go into one BRBE. Merging the settings in tools would be a much harder problem. Any user that doesn't have permission for anything in the merged result can continue to get nothing. And we can always add filtering in the kernel later on if we want to to make it appear to behave even more normally. > static int > armpmu_add(struct perf_event *event, int flags) > { > ........ > if (has_branch_stack(event)) { > /* > * Reset branch records buffer if a new task event gets > * scheduled on a PMU which might have existing records. > * Otherwise older branch records present in the buffer > * might leak into the new task event. > */ > if (event->ctx->task && hw_events->brbe_context != event->ctx) { > hw_events->brbe_context = event->ctx; > if (armpmu->branch_reset) > armpmu->branch_reset(); > } > hw_events->brbe_users++; > Here -------> hw_events->brbe_sample_type = event->attr.branch_sample_type; > } > ........ > } > > Instead of overriding existing 'branch_sample_type', both could be merged. > I can't see any use case where anyone would want the override behavior. Especially if you imagine multiple users not even aware of each other. Either the current "no records for mismatches" or the merged one make sense. James