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

Add user event as a new static userspace tracepoint tool ? #251

Open
Tropicao opened this issue Jul 29, 2024 · 1 comment
Open

Add user event as a new static userspace tracepoint tool ? #251

Tropicao opened this issue Jul 29, 2024 · 1 comment
Labels
debugging Debugging/Profiling/Tracing training enhancement New feature or request

Comments

@Tropicao
Copy link
Contributor

Tropicao commented Jul 29, 2024

The training currently shows only one way to add static tracepoints in a userspace process with LTTNG, especially with UST library.

It may be interesting to provide an alternative, which additionally does not rely on an external, possibly heavy to setup, framework (it may become even more true if we reduce the LTTNG part)
User-space events is a kernel assisted mechanism which provides another way to instrument an application. Those events rely on specific tracefs entries to register a data source and input data to it. The process to generate user events in an application is roughly the following:

  • register our new event, providing an "enable" variable address, an event name, a write index variable, etc
    • on successful registration, the kernel will update the write index variable, which must then be used each time we want to write some data
  • the program can now monitor the enable variable, which will be updated by the kernel everytime someone (perf, trace-cmd, raw tracefs access) enables or disables the corresponding event
  • when the event is enabled, the application can use the returned write index to write some data when relevant.

The kernel source tree also provides a simple-to-use sample to experiment with it:

cd ~linux/samples/user_events
make
sudo ./example

In another terminal, while the example program is running:

sudo trace-cmd list -e |grep test # We should see the registered user-event named test
sudo trace-cmd -e test
# Wait a few seconds, then Ctrl+c
trace-cmd report

We should see the following data generated by the example program:

cpus=20
         example-258900 [002] 20092.119852: test:                 count=0
         example-258900 [002] 20094.045727: test:                 count=1
         example-258900 [002] 20095.453523: test:                 count=2
         example-258900 [002] 20095.648020: test:                 count=3
         example-258900 [002] 20095.971038: test:                 count=4
         example-258900 [002] 20096.188430: test:                 count=5
         example-258900 [002] 20096.352141: test:                 count=6
         example-258900 [002] 20096.535957: test:                 count=7

EDIT: since the corresponding events are captured in ftrace buffer, those can be displayed in kernel shark when captured with trace-cmd

@Tropicao Tropicao added enhancement New feature or request debugging Debugging/Profiling/Tracing training labels Jul 29, 2024
@tpetazzoni
Copy link
Contributor

Definitely seems worth covering in the training course!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
debugging Debugging/Profiling/Tracing training enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants