You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ftrace allows collecting events in multiple user-defined instances. In trace-cmd, this is enabled by the -B switch.
Unfortunately, using non-toplevel instance has brought a number of problems:
Some events simply cannot be collected anywhere else, like bprint emitted by trace_printk(). This is "by design" in how ftrace work, so unlikely to ever get solved.
The motivation behind using instances in the first place was an attempt at isolating the impact of devlib collector so that other userspace tools could cooperate. Unfortunately, some ftrace tunables are not per-instance, and most other tools don't seem to be particularly good citizen when it comes to instances they don't own (last time we tried with Perfetto it did not allow trace-cmd running at the same time with success).
As a result, I think we should revert that choice and simply use the top-level instance. At the moment, the only ways this is exposed in devlib API are:
Generated traces have events in the "devlib" buffer. This would show up in trace-cmd report output, but I don't think anyone particularly depends on that. Even if they do, they would already have issues with bprint anyway.
FtraceCollector() has separate buffer_size and top_buffer_size parameters. We could simply aggregate both with max() and preserve the API as it is, so that we can re-introduce it in the future if the situation improves.
The text was updated successfully, but these errors were encountered:
ftrace allows collecting events in multiple user-defined instances. In trace-cmd, this is enabled by the
-B
switch.Unfortunately, using non-toplevel instance has brought a number of problems:
The motivation behind using instances in the first place was an attempt at isolating the impact of devlib collector so that other userspace tools could cooperate. Unfortunately, some ftrace tunables are not per-instance, and most other tools don't seem to be particularly good citizen when it comes to instances they don't own (last time we tried with Perfetto it did not allow trace-cmd running at the same time with success).
As a result, I think we should revert that choice and simply use the top-level instance. At the moment, the only ways this is exposed in devlib API are:
trace-cmd report
output, but I don't think anyone particularly depends on that. Even if they do, they would already have issues with bprint anyway.buffer_size
andtop_buffer_size
parameters. We could simply aggregate both withmax()
and preserve the API as it is, so that we can re-introduce it in the future if the situation improves.The text was updated successfully, but these errors were encountered: