From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 595511E1A3B for ; Thu, 17 Jul 2025 15:16:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752765398; cv=none; b=vAFtRS9baVQUz6nXfXpLjj/dkaQM9gFVR5WAo++fsQyRhpjL7InM4Wl5RSE0Q+V7bAK28wXp4Y1O5efk3TR20QrlcF4ck+a7cYS9V8HxezZumVCuZMnCOVR0GLTsME8DNagySXy07Ce33D0Am0fRIp6cTOsUL2Yt22BbAt2JjWA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752765398; c=relaxed/simple; bh=42i7QgR3Vm1XbHENgDUnhNUH1shHeEplaZfgHdiTnfI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SMl0zx1tRNnNuoW/py+NMIsDP4O3zc018NYi1NN6dr314VoXsep0zZKcDwrYXzJYl/xpsh4m9jQq1zh5kw6UCKZ9K/5lyqegWQIGSI/BdZ6iyjPytsPjSUfOf+wEk8j6HzhQhNHwj/fsI6DiWvvKTr4zaYSTb6L1gN3cBVeixEY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=VVkmqb4r; arc=none smtp.client-ip=209.85.221.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="VVkmqb4r" Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-3a6f2c6715fso885722f8f.1 for ; Thu, 17 Jul 2025 08:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1752765394; x=1753370194; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=9o9XStLuurpqMGv7dh7QCRhtG3mn+IMSEac9X1lSv4g=; b=VVkmqb4r6FLNP7jFQ0LKYP/a3iOpC0sIfd/hhZrgEzqpfF/r35LYYV9/HZzFWiYZ0U 46ywHsd77GhFh/MaCYM2VsrEoMfnQwwL1aE9L269yvD4qGE/cO3TKPMCFxQH9IRsyPrj BerdNvM6Cl+UHAHNOqooKsQOVlnV0jHNahxiS5OMWbtaQeE+8+1Wuk8HEKEKF/SJgogN nTWbv2MIAoYt1hmjp1lqmCnpBUWm/+iOyrLEJQO1jIGYOsw0e5RaknYAu4T7gf7/uDPs /+eD4AWGR6mlucA1cGDvyBtJow0vtciAKeJWmXWlA2HrmnU1NNZRtdYR1Hvk3o9K/8ro V02A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752765394; x=1753370194; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9o9XStLuurpqMGv7dh7QCRhtG3mn+IMSEac9X1lSv4g=; b=txzyPxiSlPhOuDIRlFhg9b4/1PqBUfSV0SuNnBqnsRTfY1bYsyS8pkmBwi8kWHg1qQ I8Jd+/l18zQwVfLZfyGVNt4b8RUAxP9FFJktigBLl0+izb7VxE3hA+LGsdTImfb50B5e i6T+KCynrxPw2oLbAdvCW9IU7zWyRxYSedpqYEO6pPQ7JeQAM3BlWVt4z1G5uoVHL00E YdnAUEHgC40hLKEA+6M+6rjhArbYbW/XCWtH6S8Svgz5Jy/rG29MgBPmTE5/CrUqc/EW c18q/UArd0Bl3Kz5yEDoAsVJnINWMIXuAQIBG3ruo/lGc8wlZLTaTP/2mRdhXTRp3XEp JxvQ== X-Forwarded-Encrypted: i=1; AJvYcCV1IgClpl/+YRagZaWuEgoqkkiT2WlrbpR4SEPyNZ4FiRGY+d4rtW/P6Etei6mkMIXUNvyYzyddpiL9ZUWkLTSA@vger.kernel.org X-Gm-Message-State: AOJu0YzSKcJJbfGuTt6yoHSvR4f8vCGrnCvEgMFwpLYtVBN8IPRtjrxy vne40IWXjc0ulVcZoJWdRXDu2Sdzz6xWF5oUqbP8brk8mEolPt4+e7GcLH9UWOdTG9I= X-Gm-Gg: ASbGncu8TSf+OQoQh5OilvFFtIOGIndT80mcan12r7AfLrkBgk2Stf81yoeBd+Mh07p rFMmTSdMqpF7wKH5vRhp5gJar9IXDY35e9UC/bedjjtTEI8OKvtO/JA8R0pdjCWF56icn9gzhYv CpcUGVx+/e8aLJ699WAXJ4QzVeQGD/g+yxPXH3+aFdtppJ5H6xqzNN/S1EOGRG4rkAH7kODvjSA SSKgD6Kpk/eQf556uNq7XUaPCF2hm3gFbHGKIxG48fZOfXp8bHFhaCKrQNwi26Fg+L6vWQxfITa mganjkbAKtQsRzFZP9F9jZdVsR/eCWZkBfufR1zkotoWYdFDkjbacdP1cHLbPTCZoYsMu3XLHjv jGlkGbzv4T3wPlHroGP1LSSINLBM= X-Google-Smtp-Source: AGHT+IEOgsXesc4WriF6B4s4UdXOC/523vChLTF14vUDuJL5EdaGCxaHdXKmwN46VtYnX5eN75Kjsw== X-Received: by 2002:a05:6000:40d9:b0:3b4:4876:9088 with SMTP id ffacd0b85a97d-3b60e510003mr5758377f8f.46.1752765394479; Thu, 17 Jul 2025 08:16:34 -0700 (PDT) Received: from [192.168.1.3] ([185.48.76.109]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b5f32ed100sm18096525f8f.0.2025.07.17.08.16.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Jul 2025 08:16:33 -0700 (PDT) Message-ID: Date: Thu, 17 Jul 2025 16:16:32 +0100 Precedence: bulk X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 07/10] perf: arm_spe: Add support for filtering on data source To: Will Deacon Cc: Catalin Marinas , Mark Rutland , Jonathan Corbet , Marc Zyngier , Oliver Upton , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , leo.yan@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev References: <20250605-james-perf-feat_spe_eft-v3-0-71b0c9f98093@linaro.org> <20250605-james-perf-feat_spe_eft-v3-7-71b0c9f98093@linaro.org> <7f51d4f9-7e08-49b5-ab43-8bc765bb2ca8@linaro.org> Content-Language: en-US From: James Clark In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 17/07/2025 3:29 pm, Will Deacon wrote: > On Tue, Jul 15, 2025 at 02:04:18PM +0100, James Clark wrote: >> On 14/07/2025 3:04 pm, Will Deacon wrote: >>> On Thu, Jun 05, 2025 at 11:49:05AM +0100, James Clark wrote: >>>> @@ -406,6 +416,9 @@ static u64 arm_spe_event_to_pmsfcr(struct perf_event *event) >>>> if (ATTR_CFG_GET_FLD(attr, inv_event_filter)) >>>> reg |= PMSFCR_EL1_FnE; >>>> + if (ATTR_CFG_GET_FLD(attr, data_src_filter)) >>>> + reg |= PMSFCR_EL1_FDS; >>> >>> Is the polarity correct here? The description of PMSDSFR_EL1.S suggests >>> that setting bits to 1 _excludes_ the FDS filtering. >>> >> >> Setting filter bits to 1 means that samples matching are included. Setting >> bits to 0 means that they are excluded. And PMSFCR_EL1.FDS enables filtering >> as a whole, so if the user sets any filter bit to 1 we want to enable >> filtering: >> >> PMSDSFR_EL1.S >> >> 0b0 If PMSFCR_EL1.FDS is 1, do not record load operations that have >> bits [5:0] of the Data Source packet set to . >> >> 0b1 Load operations with Data Source are unaffected by >> PMSFCR_EL1.FDS. >> >> I think it's all the right way around and it ends up being the same as the >> other filters in SPE. Because we're using any bit being set to enable the >> filtering, the only thing you can't do is enable filtering with a 0 filter, >> but I didn't think that was useful. See the previous discussion on this >> here: >> https://lore.kernel.org/all/5752f039-51c1-4452-b5df-03ff06da7be3@linaro.org/ >> >> Reading the "Data source filtering" section in the docs change at the end >> might help too. > > Sorry, but I still don't get it :/ > > afaict, if any of the bits in 'data_src_filter' are _zero_ then we > should set PMSFCR_EL1.FDS. That also means that a mask of zero means all > loads are filtered, which is what the architecture says and is what we > should provide to userspace. > > Will We'd have to add another format flag to enable data source filtering then, because otherwise the default would be zero and people's samples would disappear. But the only use cases I could think of were more like "I want to see samples from data source 1": -e arm_spe/data_src_filter=0x1/ Or "I want to see all data sources except 1": -e arm_spe/data_src_filter=0xfffffffe/ Filtering out all samples with any data source didn't seem to make sense to me, and I think you can already do that with the other filters (remove loads etc). It would be a shame to be inconsistent and to add an enable flag just for that one case because the other filters in SPE are auto enabled for non-zero values. Although to be fair for PMSFCR.FT and others, zero filters are explicitly not allowed: If this field is set to 1 and the PMSFCR_EL1.{ST, LD, B} bits are all set to zero, it is CONSTRAINED UNPREDICTABLE whether no samples are recorded or the PE behaves as if PMSFCR_EL1.FT is set to 0 Seems like FDS doesn't end up as neat as the others, but IMO I can't see anyone needing a zero filter. I did discuss it with Leo and we decided that we could always add the enable flag at a later date if a use case turned up and it wouldn't be a breaking change. But if you think it's there so it should be exposed I can add it. James