Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop using ftrace non-toplevel instance #717

Open
douglas-raillard-arm opened this issue Mar 14, 2025 · 0 comments
Open

Stop using ftrace non-toplevel instance #717

douglas-raillard-arm opened this issue Mar 14, 2025 · 0 comments

Comments

@douglas-raillard-arm
Copy link
Collaborator

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:

  1. 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.
  2. Other ftrace features such as synthetic events do not play well with non-toplevel instance

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:

  1. 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.
  2. 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant