Hi Leo
On Wed, 12 Nov 2025 at 13:56, Leo Yan leo.yan@arm.com wrote:
Hi Mike,
On Wed, Nov 12, 2025 at 11:58:26AM +0000, Mike Leach wrote:
[...]
I prefer we can use a separate patch series to address this issue (I should review Levi's patch series so can make things proceed). At the meantime, I would say this patch is still valid.
As a side topic, actually we have found issues for the config is reset when start a session so the user's config does not take affect at all (see etm4_set_default_config()).
This code is used by the perf session - not the sysfs session. This is deliberate to start from a stable state and add any configuration from the perf command line.
My feeling is now the discussion mixes up two things:
Should we apply user's parameters (via sysfs knobs) on a perf session?
Can a perf session overwrite user's parameters?
For me, there is no reason to prevent a perf session from using the user's configs. We might disagree on this, but regarding the second question, a perf session definitely should not overwrite the user's parameters — it can ignore the user's configuration, but it must not erase these parameters.
The perf session deliberately ignores parameters set by sysfs - in fact the first act in parsing the perf event structure in etm4_parse_event_config(), is to completely zero out the entire config structure. Then the default config is set - which guarantees trace is captured, then any perf command line options are set in the registers (e.g. timestamps, address filtering etc). After this if we have s cscfg configuration active, this too is added in.
Seems to me, a correct sequence is:
- Clean up hw_config;
- Apply user's config on hw_config;
The configuration system was designed precisely to implement the concept of a "users config" without the unnecessary burden of having to program up all the ETMs via sysfs in a multicore system.
The users config you describe is simply repeating work already done.
The danger in using sysfs configuration is that the perf session cannot possibly know if it was set by the current user of the resources or left over from a previous session.
The only elements that should affect a perf session should be those that appear on the perf command line - these being the traditional commands + a named configuration if present. This means that the owner of the perf session is 100% sure of what is being requested.
Changing the configuration of a perf session via some backdoor sysfs additions is unacceptable.
Regards
Mike
- Apply cscfg on hw_config.
- Apply perf's format/config on hw_config;
In this sequence, the last applying config has highest priority (as the perf format is the latest setting from user).
Here I am not quite sure for step 2) and 3). Should we apply both user's config and cscfg, or we apply only one and ignore another (e.g., if cscfg has been set, then ignore user's config, vice versa).
This ensures that the configuration run on all the ETMs used during the perf session is identical - which cannot be guaranteed if we used sysfs set parameters as part of the perf session, as each ETM might have different parameters set by sysfs.This gives us predictable, stable and repeatable perf configurations.
Why can't we leave this to users?
For sanity, drivers should reject invalid parameters when a user is setting it, once the parameters are accepted, afterwards drivers should simply follow the user's settings in a runtime session.
Thanks, Leo