Re: [PATCH v9 2/5] perf: arm_spe: Add support for filtering on data source

[James Clark]

On 10/11/2025 3:48 pm, Peter Zijlstra wrote:
> On Wed, Oct 29, 2025 at 03:46:02PM +0000, James Clark wrote:
> > SPE_FEAT_FDS adds the ability to filter on the data source of packets.
> > Like the other existing filters, enable filtering with PMSFCR_EL1.FDS
> > when any of the filter bits are set.
> >
> > Each bit maps to data sources 0-63 described by bits[0:5] in the data
> > source packet (although the full range of data source is 16 bits so
> > higher value data sources can't be filtered on). The filter is an OR of
> > all the bits, so for example clearing bits 0 and 3 only includes packets
> > from data sources 0 OR 3.
> >
> > Invert the filter given by userspace so that the default value of 0 is
> > equivalent to including all values (no filtering). This allows us to
> > skip adding a new format bit to enable filtering and still support
> > excluding all data sources which would have been a filter value of 0 if
> > not for the inversion.
>
> So from that I'm reading the config4 field will only have like 16 bits,

The _data source_ is 16 bits, but the _data source filter_ is 64 bits.

> but here:
>
> > +#define ATTR_CFG_FLD_inv_data_src_filter_CFG	config4	/* inverse of PMSDSFR_EL1 */
> > +#define ATTR_CFG_FLD_inv_data_src_filter_LO	0
> > +#define ATTR_CFG_FLD_inv_data_src_filter_HI	63
>
> you claim all 64 bits.
>
> Also, afaict:
>
>    #define ATTR_CFG_FLD_min_latency_CFG            config2 /* PMSLATFR_EL1.MINLAT */
>    #define ATTR_CFG_FLD_min_latency_LO             0
>    #define ATTR_CFG_FLD_min_latency_HI             11
>
> Still has more than 16 bits left.
>
>
> So why exactly are we needing config4? Can we please get a more solid
> argument?

Each filter bit position maps onto one numerical data source value. The 
16 bit field in the data source packet gives us possible data sources 
from 0 - 65535. The 64 bits of the filter allow us to filter on a subset 
of data sources (0 - 63), but that uses all 64 bits of the filter with 
one bit used for each source.

I think you are assuming the data source filter can only filter on a 
single value as if it was interpreted numerically, rather than bitwise? 
But it's actually interpreted as a separate filter for each bit, which 
allows the OR semantics that are described in the commit message.

It might be clearer if I add a few more words to differentiate "data 
source" and "filter":

  Each bit of the 64 bit filter maps to data sources 0-63 described by
  bits[0:5] in the data source packet (although the full range of data
  source is 16 bits so higher value data sources can't be filtered on).
  The filter is an OR of all the filter bits, so for example clearing
  filter bits 0 and 3 only includes packets from data sources 0 OR 3.