| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The 'trace-cmd split' command conserves all buffers/instances
of the input .dat file. Add support to select the instances to
keep:
- '--top' to keep the top instance
- '-b' top rename the top instance. Must follow '--top'.
- '-B buffer' to keep a buffer/instance
- t top promote a buffer to the top instance.
Must follow '-B'.
For example, with a trace recorded with:
$ trace-cmd record -e sched_wakeup -B switch_instance \
-e sched_switch
Creating a test.dat file containing the top instance and
the switch_instance:
$ trace-cmd split --top -B switch_instance -o test.dat
Creating a test.dat file containing the switch_instance as
the top instance, and the initial top instance as an instance
named 'old_top':
$ trace-cmd split --top -b old_top -B switch_instance -t \
-o test.dat
Also update the trace-usage.c and the relevant documentation
for the new options.
Link: https://lore.kernel.org/linux-trace-devel/20240222165418.2153026-2-pierre.gondois@arm.com
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
(struct handle_list).name was unnecessarily made const in:
commit caa9eda091d6 ("trace-cmd split: Store instances in local list")
Remove it.
Also fix bad indentation.
Link: https://lore.kernel.org/linux-trace-devel/20240222165418.2153026-1-pierre.gondois@arm.com
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
In some setups PATH_MAX may not be defined (it is usually defined in
linux/limits.h), but we just use PATH_MAX as something to hold the paths
to the tracing files. In that case, just define it to 1024 if it's not
already defined.
Link: https://lore.kernel.org/linux-trace-devel/20240222-utest-fixes-v2-1-7b8ee8dca0b7@gmail.com/
Link: https://lore.kernel.org/linux-trace-devel/20240222110604.156aa6bb@gandalf.local.home
Reported-by: Miko Larsson <mikoxyzzz@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When using --poll, move_data() returns -1 and errno is set to EAGAIN.
This causes the record threads to stop recording.
Fix it by returning to the read loop in case EAGAIN, if --poll
is specified.
Link: https://lore.kernel.org/linux-trace-devel/ZbgNqiyocHf/FEQw@tpad
Fixes: 2610bdcde43a6 ("trace-cmd library: Use tracefs_cpu for recorder helpers")
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If the input file that is being split does not contain a 'cmdline'
section, do not fail. The section is optional.
Link: https://lore.kernel.org/linux-trace-devel/20240116211415.41b530e5@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
trace-cmd can record events in multiple instances:
$ trace-cmd record -e sched_wakeup -B test_instance -e sched_switch
When trying to split a trace.dat file recorded with the above command,
only the events located in the main buffer seems to be split. The
events recorded in the test_instance buffer seem to be discarded:
$ trace-cmd split -i trace.dat -o trace_2.dat 284443 284444
$ trace-cmd report trace_2.dat
cpus=8
<...>-525991 [004] 284443.173879: sched_wakeup: [...]
<...>-525991 [004] 284443.173879: sched_wakeup: [...]
<...>-525990 [007] 284443.173885: sched_wakeup: [...]
<...>-525990 [007] 284443.173885: sched_wakeup: [...]
(no sign of sched_switch events)
Keep all instances/buffers of a trace when it is split.
Also add a 'get_handle()' function.
Link: https://lore.kernel.org/linux-trace-devel/20240123134215.385415-4-pierre.gondois@arm.com
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=218357
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
To prepare handling of multiple instances and storing them
in temporary files, add utility functions generating file names,
removing files, creating files:
- get_temp_file()
- delete_temp_file()
- put_temp_file()
- touch_file()
Also make use these functions.
Link: https://lore.kernel.org/linux-trace-devel/20240123134215.385415-3-pierre.gondois@arm.com
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
To prepare handling of multiple instances, store instance
handles in a local list, similarly to what is currently
done in tracecmd/trace-read.c.
To help achieve this goal, add a 'struct handle_list' and
add_handle()/free_handles() functions. 'struct handle' elements
are added to the static list, but not used in this patch.
Link: https://lore.kernel.org/linux-trace-devel/20240123134215.385415-2-pierre.gondois@arm.com
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If trace-cmd report is called with a single file that is not specified by
the -i option, it will report it. But if it is called with multiple files,
it will only report the first one. Allow all the trace.dat files at the
end of options to be considered files to read.
That is, currently if you have:
trace-cmd record -e sched sleep 100
trace-cmd split -r -m 100 -o trace-split.dat
trace-cmd report trace-split.dat.*
It will only show the report of trace-split.dat.0001 and not the rest. To
get the rest, each one would need to be included with -i. Instead, allow
them all to be reported with the above command.
Link: https://lore.kernel.org/linux-trace-devel/20240124132231.638e148a@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The code fix to correctly split start/end/time-window parameters removed
an initialization of "current" which can now fall out being uninitialized
and used for a later compare.
Found with valgrind.
Link: https://lore.kernel.org/linux-trace-devel/20240124122832.4e0b33b7@gandalf.local.home/
Link: https://lore.kernel.org/linux-trace-devel/20240124124927.3551e982@gandalf.local.home
Cc: Pierre Gondois <pierre.gondois@arm.com>
Fixes: 1439b8f518 ("trace-cmd split: Correctly split with start/end/time-window parameters")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
With a trace.dat file having events timestamped between
[284443.0, 284448.0] seconds, the following command:
trace-cmd split -i trace.dat -o trace2.dat -r -m 100 284444 284445
should produce ten trace2.dat.XXX files between [284444.0, 284445.0],
each one lasting 100ms.
Currently only one trace2.dat.001 file is produced, with events
within the [284444.0, 284445.1] time window.
Don't stop splitting the input file after the first iteration.
Add a end_reached to detect when the end timestamp is reached.
Link: https://lore.kernel.org/linux-trace-devel/20240122164336.167256-3-pierre.gondois@arm.com
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Small fixes:
- Remove a useless assignment to 'current' variable.
- Fix returned type of parse_file()
Link: https://lore.kernel.org/linux-trace-devel/20240122164336.167256-2-pierre.gondois@arm.com
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If the -o comes after a -B, the output_file name will be associated to the
trace instance of that -B, and the top_instance.output_file will be NULL.
If recording is started in a location that is read-only, the temp file
created for the top instance is going to try to be created in that read-only
file system.
/sys/kernel/tracing# trace-cmd record -o /tmp/test.dat -B test -e sched
Hit Ctrl^C to stop recording
^Ctrace-cmd: Permission denied
could not create file (null).cpu0
Make sure all instances, including the top_instance has their output_file
correct.
Also, because the output file could have been created under another
instance, check if that instance already has the output file before
assigning over it.
Link: https://lore.kernel.org/linux-trace-devel/20240119162743.1a107fa9@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Save the current buffer_size_kb and subbuf_size_kb files before updating
them, and put them back to what they were when finished with recording.
Link: https://lore.kernel.org/linux-trace-devel/20240110230303.118668-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add an option that will change the sub-buffer size if the kernel supports
it.
Also change the '-b' option that changes the buffer size to use the
libtracefs helper function: tracefs_instance_set_buffer_size().
Link: https://lore.kernel.org/linux-trace-devel/20240110230303.118668-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The meson build was missing trace-sqlhist.c.
Link: https://lore.kernel.org/linux-trace-devel/20240111192022.37bd4602@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add more tests to test tracecmd_iterate_events() and
tracecmd_iterate_events_reverse(), as well as stopping and restarting.
Link: https://lore.kernel.org/linux-trace-devel/20240111172530.5a54859e@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The iterators cache the records via a tracecmd_peek_data() to find the next
CPU record to use. The problem is that the callback() may do a
tracecmd_read_data() (the function graph plugin does) and this may
invalidate the cached record. It would require refreshing every record of
every cached CPU after every callback, which can be expensive.
Since only the timestamps of the records are needed, simply cache the
timestamp of the record to find which is the next CPU record to use. After
finding the CPU that has the earliest timestamp, do a tracecmd_peek_data()
test again to make sure the timestamp still matches the record. If it does,
then simply use that record, if not, refresh the timestamp for that CPU and
try again.
Link: https://lore.kernel.org/linux-trace-devel/20240111222201.154686-4-rostedt@goodmis.org
Fixes: 2cb6cc2f4 ("tracecmd library: Add tracecmd_iterate_events()")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
I'm not sure why the records that were saved in the "peek" were freed, as
they should be freed when the tracecmd_input is closed.
Remove the freeing of the "peek" records, as it should be unneeded.
This basically reverts:
890855541 ("tracecmd library: Unlock records in tracecmd_iterate_events()")
And commits that simulated it.
Link: https://lore.kernel.org/linux-trace-devel/20240111222201.154686-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The handle->cpu_data[cpu]->max_cpu is the largest number CPU that is
recorded in the trace, where as cpu_data[cpu]->cpus is the number of
handle->cpu_data[] entries.
The iterator loops mistakenly used the max_cpu field instead of the cpus
field and this can cause errors if the two are not the same. This is the
case if one of the CPUs contained no data, it will not have a cpu_data[]
entry and will be skipped.
Link: https://lore.kernel.org/linux-trace-devel/20240111222201.154686-2-rostedt@goodmis.org
Fixes: 2cb6cc2f4 ("tracecmd library: Add tracecmd_iterate_events()")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The kerneldoc header of tracecmd_cpus() is tracecmd_page_size() and not
tracecmd_cpus(). Fix it.
Link: https://lore.kernel.org/linux-trace-devel/20240111171504.20d585ae@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If the handle->cpu_data[cpu].page has been freed and cleared, consider the
last event to be empty. This can happen if the buffer size is zero.
(Should we add a warning if page is NULL and size is not zero?)
Link: https://lore.kernel.org/linux-trace-devel/20240111171352.5bd23613@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The function graph tracer has two events. One for the entry of a function,
and one for the exit. The ftrace tracing plugin will check the next event,
and if the exit event of a function follows directly after the entry of the
same function, it will combine them to look like:
123.456 us | func();
If some other event were to be between the events, then it will break it up:
| func() {
54.321 us | other_func();
123.456 us | }
But this could hide that a function migrated across CPUs.
For example:
migrate-14353 [001] dN.1. 66420.851920: funcgraph_entry: + 43.090 us | exit_to_user_mode_prepare();
Hides that the migrate program migrated between the entry of
exit_to_user_mode_prepare() and the exit, where looking at each event there is:
migrate-14353 [001] dN.1. 66420.851920: funcgraph_entry: | exit_to_user_mode_prepare() {
migrate-14353 [003] d.... 66420.851963: funcgraph_exit: + 43.090 us | }
Where it migrated from CPU 1 to 3.
Worse, it confuses the idle for which CPUs they were run on and for how long:
<idle>-0 [007] ...2. 66420.073288: funcgraph_entry: ! 268.817 us | do_idle();
<idle>-0 [004] ...2. 66420.073315: funcgraph_entry: ! 258.832 us | do_idle();
<idle>-0 [005] ...2. 66420.073323: funcgraph_entry: ! 157.311 us | do_idle();
Instead of:
<idle>-0 [007] ...2. 66420.073288: funcgraph_entry: | do_idle() {
<idle>-0 [004] ...1. 66420.073315: funcgraph_exit: ! 268.817 us | }
<idle>-0 [004] ...2. 66420.073315: funcgraph_entry: | do_idle() {
<idle>-0 [005] ...1. 66420.073322: funcgraph_exit: ! 258.832 us | }
<idle>-0 [005] ...2. 66420.073323: funcgraph_entry: | do_idle() {
<idle>-0 [000] ...1. 66420.073330: funcgraph_exit: ! 157.311 us | }
Where the first one shows 268.817us for CPU 7 when it was really for CPU 4.
Link: https://lore.kernel.org/linux-trace-devel/20240111171305.0bb529f0@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The offset exposed to the callers of libtracecmd is the uncompressed file
offset. The read_zpage() subtracts the fake uncompressed offset to get to
the compressed data offset.
The free_zpage() did not subtract the uncompressed offset so it was not
finding the cached compressed data it was looking for to free, and left the
page not freed.
Subtract the uncompressed file offset from the passed in offset to find the
cached node to free.
Link: https://lore.kernel.org/linux-trace-devel/20240111171207.54d7cdbf@gandalf.local.home
Fixes: add83e0c8b511 ("trace-cmd library: Fix tracecmd_read_at()")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
In the Linux kernel version 3.3 the default output showed the irq information
that is typically only for the latency format. That is, it shows:
<idle>-0 [000] d..2 49.309305: cpuidle_get_driver <-cpuidle_idle_call
<idle>-0 [000] d..2 49.309307: mwait_idle <-cpu_idle
<idle>-0 [000] d..2 49.309309: need_resched <-mwait_idle
Instead of:
<idle>-0 [000] 49.309305: cpuidle_get_driver <-cpuidle_idle_call
<idle>-0 [000] 49.309307: mwait_idle <-cpu_idle
<idle>-0 [000] 49.309309: need_resched <-mwait_idle
After 12 years, it's about time that the default trace-cmd report output did
the same!
This does change the output format and possibly can break anything that
tries to parse it.
Link: https://lore.kernel.org/linux-trace-devel/20240108191759.5fc4ecda@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Show the sub-buffer size if the file system supports it and it is different
than the architecture page size.
This requires libtracefs 1.8, so update the Makefile with that
requirement.
Link: https://lore.kernel.org/linux-trace-devel/20240108184123.62f9be6b@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
In the rbtree deletion, the deletion had the logic:
if (!node->left || !node->right)
y = node;
else
y = next_node(node);
if (y->left)
x = y->left;
else
x = y->right;
x->parent = y->parent;
Where if the node had both right and left, the y returned would not have
children. This is fine, but the x would be NULL. In that case, do not update
the parent of x. But instead, skip over and continue the work. As x->parent
would be the same as y->parent, instead of checking the x->parent (where x
could be NULL), check y->parent, which is already known to be the same as
x->parent if x is not NULL.
Also add another check_tree() at the end of the deletion routine.
Link: https://lore.kernel.org/linux-trace-devel/20240110103941.2e26da60@gandalf.local.home
Fixes: 5274db32a ("libtracecmd: Use an rbtree for mapping of cache pages")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=218357
Reported-by: pierre.gondois@arm.com
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
There was a bug where a "trace-cmd record -B foo" would delete the foo
instance when the record was finished even if that instance previously
existed. But that fix was a bit too agreesive. It changed two places:
1) where the bug was, in remove_instance()
2) where the bug was not, in tracecmd_remove_instance() that uses the
instance->flags to know if it should be deleted or not.
The "trace-cmd reset" uses the latter function and if the "-d" option is
set, it is supposed to delete the instance. But because that function was
changed to only delete it if it created it (which reset does not do), it
broke it.
Link: https://lore.kernel.org/linux-trace-devel/20240109231751.1e49addd@gandalf.local.home
Fixes: 9d6f3baa3 ("trace-cmd record/extract: Do not destroy existing instances")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add tests to test the trace-cmd sqlhist command as well as the
trace-cmd show --hist and --trigger options.
Link: https://lore.kernel.org/linux-trace-devel/20240106042428.279706-4-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add the 'sqlhist' command that uses tracefs_sql to create histograms or
synthetic event. This is taken from the libtracefs tracefs_sql() sample that
does basically the same thing.
Link: https://lore.kernel.org/linux-trace-devel/20240106042428.279706-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add the option --hist [<system>:]<event> to show the histogram output of a
given event, and --trigger [<system>:]<event> to show the content of the
trigger file.
Link: https://lore.kernel.org/linux-trace-devel/20240106042428.279706-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
A red black tree implementation was recently added but it only enabled
for the make build process. Add it also to the meson build.
Link: https://lore.kernel.org/linux-trace-devel/20231205105826.16428-1-dwagner@suse.de
Fixes: 5274db32a7ef ("libtracecmd: Use an rbtree for mapping of cache pages")
Signed-off-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
In --tsync-interval option documentation, remove extra characters that
should not be there.
Link: https://lore.kernel.org/linux-trace-devel/20231107223244.1121582-1-yoann.congal@smile.fr
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Instead of open coding reading an instance file, use the libtracefs
library tracefs_instance_file_read().
Link: https://lore.kernel.org/linux-trace-devel/20231229031907.69432-5-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add trace-cmd show --buffer_percent to show the value of the buffer_percent
file.
Link: https://lore.kernel.org/linux-trace-devel/20231229031907.69432-4-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add an option to trace-cmd show that displays the subbuffer size in
kilobytes.
Link: https://lore.kernel.org/linux-trace-devel/20231229031907.69432-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
To simplify adding enums to trace-cmd show, re-arrange the enum values. They
can be larger than 255 as well.
No functional changes.
Link: https://lore.kernel.org/linux-trace-devel/20231229031907.69432-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Currently there's no easy way to reset iterating over a trace.dat file if a
tracecmd_iterate_events() was called. Add a helper function to do that:
tracecmd_iterate_reset()
Link: https://lore.kernel.org/linux-trace-devel/20231229031138.68313-4-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
tracecmd_stack_tracer_status()
A clean up was made to remove all the settings of errno to zero in the
library, but it was a bit too aggressive in doing so. It removed the errno
setting to zero in tracecmd_stack_tracer_status() just before it called
strtol() which it uses to test for the success of that function. By not
clearing errno, it was causing trace-cmd stat to report:
"Error reading stack tracer status"
Link: https://lore.kernel.org/linux-trace-devel/20231229031138.68313-3-rostedt@goodmis.org
Fixes: dcd5ee3142 ("libtracecmd: Do not set errno to zero")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
In tracecmd_iterate_events_multi(), the clean up code at the end of the
function that unlocks and frees the remaining records, iterated the CPUs via
a for loop of 0 through all_cpus. But the kbuffer_read_at_offset() function,
expects the CPU passed in to be that of the handle and not of all the
handles.
That is, if there are two trace.dat files being read, and one has 4 CPUs and
the other has 2, the "all_cpus" variable will be 6. When iterating at the
clean up, when it gets passed 3 (4 CPUs is represented by 0-3) it will then
go to 4 and then 5 for the 2 CPUs trace.dat file. Passing in 4 or 5 to
kbuffer_read_at_offset() will fail. It needs to use the local CPU count of
the trace.dat file.
Link: https://lore.kernel.org/linux-trace-devel/20231229031138.68313-2-rostedt@goodmis.org
Fixes: 7f0a59aef63c1 ("trace-cmd library: Have tracecmd_iterate_events() start where it left off")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
I was loading a very large trace.dat file into kernelshark when it just
stopped near the end off the load and hung there for a very long time. I
ran it under gdb and hit Ctrl^C when it hit the hang to see what it was
doing and found that it was spinning in:
libtracecmd trace-input.c: free_zpage
static void free_zpage(struct cpu_data *cpu_data, void *map)
{
struct zchunk_cache *cache;
list_for_each_entry(cache, &cpu_data->compress.cache, list) {
if (map <= cache->map && map > (cache->map + cache->chunk->size))
goto found;
}
return;
found:
It seems that there can be over 10 thousand cache pages in that link
list and that kernelshark is constantly hitting that. So it's doing a
linear search for the mapped page to free it.
I ran: time kernelshark trace.dat
And exited out when it finished loading and the result was:
real 6m14.772s
user 6m0.649s
sys 0m12.718s
That's over 6 minutes to load the trace.dat file!!!
I ran perf record on it and it showed 77% of the time was in free_zpage().
I pulled out my old algorithms book and wrote up a rbtree for internal use
of libtracecmd. Then I switched the cache into a binary rbtree to do the
look ups. As the lookups used both where the memory of the compressed page
is mapped as well as the offset depending on how the search was done, I
found that it only used the memory allocation address in one location.
Luckily, the memory allocation mapping lookup also had access to the
offset of the file the memory represented. That allowed me to make all
lookups use the file offset.
After converting the cache to an rbtree lookup, I ran kernelshark again on
opening that file and exited out as soon as it finished loading and the
timings was:
real 1m22.356s
user 1m10.532s
sys 0m10.901s
Still a bit long, but it dropped from over 6 minutes to under 1 1/2
minutes. Also, free_zpages() was no longer in the perf record output.
Running the same file under trace-cmd produced:
Without this change:
$ time trace-cmd report trace.dat > /dev/null
real 9m20.390s
user 9m16.391s
sys 0m3.529s
With this change:
$ time trace-cmd report trace.dat > /dev/null
real 6m22.935s
user 6m19.537s
sys 0m3.139s
Not as drastic as the KernelShark speedup, but still brings it down by a
third.
Link: https://lore.kernel.org/linux-trace-devel/20231128164713.3d8d4955@gandalf.local.home
Cc: Yordan Karadzhov <y.karadz@gmail.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Julia Lawall <Julia.Lawall@inria.fr>
Cc: Ross Zwisler <zwisler@google.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
As strtok_r() modifies the string it is parsing, using the environment variable
PATH to find the paths for execution causes it to be truncated when reused by
exec. Instead, make a copy of the PATH environment variable to use to parse the
paths.
I had this fixed in my repo for some time and never pushed it out, but it was
eventually reported by others.
Link: https://lore.kernel.org/all/20231128192435.36507-1-void@manifault.com/
Link: https://lore.kernel.org/linux-trace-devel/20231128153024.6e0d40e1@gandalf.local.home
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Reported-by: David Vernet <void@manifault.com>
Reviewed-by: David Vernet <void@manifault.com>
Fixes: edf9424029cc ("trace-cmd: Open code execvp routine to avoid multiple execve syscalls")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The variable that checks return status in daemonize_start() is "rc". To be
consistent with the rest of the code, change it to "ret".
Also check for less than zero instead of -1.
Link: https://lore.kernel.org/linux-trace-devel/20231017233503.2205514-3-rostedt@goodmis.org
Cc: Avidan Borisov <avidanborisov@gmail.com>
Cc: Ross Zwisler <zwisler@google.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Currently --daemonize expects a SIGINT to stop the daemon and build the
trace.dat file. But if the user just does a:
kill <pid>
it will send a SIGTERM. This will actually kill the process and it will
not create the trace.dat file, leaving a bunch of trace.dat.cpuX files
just lying around.
Update it to also do the same with SIGTERM.
Link: https://lore.kernel.org/linux-trace-devel/20231017233503.2205514-2-rostedt@goodmis.org
Cc: Avidan Borisov <avidanborisov@gmail.com>
Cc: Ross Zwisler <zwisler@google.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a small usage example of how --daemonize can be used with guest/host tracing for analyzing network activity.
Link: https://lore.kernel.org/linux-trace-devel/20230626091635.3002827-5-avidanborisov@gmail.com
Signed-off-by: Avidan Borisov <avidanborisov@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When used with --daemonize, create a pidfile at
/var/run/trace-cmd-record.pid during the duration
of the recording, and delete it after we're done.
Link: https://lore.kernel.org/linux-trace-devel/20230626091635.3002827-4-avidanborisov@gmail.com
Signed-off-by: Avidan Borisov <avidanborisov@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
trace-listen.c has some utility functions for creating and removing
pidfiles, to avoid code duplication we make those functions generic
and export them to the rest of the codebase.
Link: https://lore.kernel.org/linux-trace-devel/20230626091635.3002827-3-avidanborisov@gmail.com
Signed-off-by: Avidan Borisov <avidanborisov@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a --daemonize flag to trace-cmd record which allows the user to record
in the background, after tracing has completely initialized.
Link: https://lore.kernel.org/linux-trace-devel/20230626091635.3002827-2-avidanborisov@gmail.com
Signed-off-by: Avidan Borisov <avidanborisov@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If the user specifies an output file, and it is not the same as the input
file, and the '-r' (repeat) option is not specified, there's no reason to
append the '.1' to the output file name. Just use what the user specified.
Link: https://lore.kernel.org/linux-trace-users/VE1PR09MB3535FFA94A0481583EF7992CF230A@VE1PR09MB3535.eurprd09.prod.outlook.com/
Link: https://lore.kernel.org/linux-trace-devel/20230710123914.5a58be62@gandalf.local.home
Suggested-by: Sharon Gabay <Sharon.Gabay@mobileye.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add an iterator that starts at the end of a trace.dat file and iterates
the events backward in time. That is, the first event will be the last
event in the file, followed by the previous event, etc. This is useful for
looking into what caused an event.
A flag is also added to continue where it last left off, as the end of the
file is not a normal location, it doesn't make sense to have it start
where it last left off like tracecmd_iterate_events() does.
The use case that inspired this change is to analyze cyclictest latency.
First the print of the failed threshold must be found, which is at the end
of the trace. Then the event of the wake up before the failed trace has to
be found, and so on. Having a way to iterate backward is helpful in this
case.
Link: https://lore.kernel.org/linux-trace-devel/20230616160228.4c9f97d8@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
New APIs are going to be added, so up the Makefile to show that the
library is now in the 1.5 version.
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The creation of the temp files for creating the split did the following:
output = strdup(output_file);
dir = dirname(output);
base = basename(output);
The problem with the above is that dirname() modifies "output" to add a
'\0' after the directory name. That is, if we had output_file = '/tmp/test';
Then the following will happen:
output = copy of "/tmp/test"
dir = dirname(output);
This will set dir to "/tmp" and insert a '\0' into the second '/'. This
also has the side effect of changing output to "/tmp" as well.
Then to get the base name:
base = basename(output);
base will end up as "tmp" and not as "test". The temp file will then be:
ret = asprintf(&file, "%s/.tmp.%s.%d", dir, base, cpu);
"/tmp/.tmp.tmp.1"
This is incorrect, as it should have been "/tmp/.tmp.test.1".
This can easily be fixed by swapping the assignment of dir and base:
base = basename(output);
dir = dirname(output);
As then, after the assignment of base, base would be "test" and output
would still be "/tmp/test", allowing for dir to get "/tmp".
Link: https://lore.kernel.org/linux-trace-users/VE1PR09MB3535122A0DA44242886307B9F233A@VE1PR09MB3535.eurprd09.prod.outlook.com/
Link: https://lore.kernel.org/linux-trace-devel/20230710125031.0e140727@gandalf.local.home
Reported-by: Sharon Gabay <Sharon.Gabay@mobileye.com>
Fixes: d9b58d42c43c2 ("trace-cmd: Fix temp files in trace-cmd split to include directories")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When a callback to tracecmd_iterate_events() returns non-zero, it exits
the iteration. Allow a sequential call to tracecmd_iterate_events() to
start were it left off.
The iterator peeks at the data which needs to be cleared. But the peek
itself set the next read to be the next record. On a sequential iterator
call, it will not include the cached records that were left over from the
previous iterator call.
Make sure at the end of the iterator to reset the indexes so that the next
reads will be the recorders that were not processed by the iterator.
Also do the same for tracecmd_iterate_events_multi() and remove the stale
comment about not needing to free the records.
Link: https://lore.kernel.org/linux-trace-devel/20230615131216.1fc36f0f@gandalf.local.home
Fixes: 2cb6cc2f4e556 ("tracecmd library: Add tracecmd_iterate_events()")
Fixes: b37903ae5fb53 ("tracecmd library: Add tracecmd_iterate_events_multi()")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
In the man page for tracecmd_iterate_events() it states that if the
callback() returns anything other than zero, it will exit the iterator.
But this is not true. It only exits if the callback returns less than
zero. This is a bug as the code should do what the man page states. Have
it exit the loop if the callback returns non zero.
Link: https://lore.kernel.org/linux-trace-devel/20230615131135.123e38af@gandalf.local.home
Fixes: 2cb6cc2f4e556 ("tracecmd library: Add tracecmd_iterate_events()")
Fixes: b37903ae5fb53 ("tracecmd library: Add tracecmd_iterate_events_multi()")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Older version of meson do not add automatically the pthread and dl
dependency. Thus add it explicitly to the build.
Link: https://lore.kernel.org/linux-trace-devel/20230615174500.9158-2-dwagner@suse.de
Cc: Tony Jones <tonyj@suse.com>
Signed-off-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Older version of meson do not add automatically the pthread and dl
dependency. Thus add it explicitly to thebuild.
Link: https://lore.kernel.org/linux-trace-devel/20230615174500.9158-1-dwagner@suse.de
Cc: Tony Jones <tonyj@suse.com>
Signed-off-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The meson patches were created before the attach program was created. Add
that to the meson list of files to build.
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add support for building the project with meson.
trace-cmd depends on a statically linked libtracecmd
(e.g. trace_perf_open, trace_perf_close, trace_perf_init).
Instead depending libtracecmd to be compiled and installed
separately add libtracecmd directly to trace-cmd build. This
avoids an additional step.
We still are able to build libtracecmd as stand alone project.
The top meson.build file just lives in the lib directory.
Link: https://lore.kernel.org/linux-trace-devel/20230208091204.7443-3-dwagner@suse.de
Signed-off-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add support for building the project with meson.
As libtracecmd lives in the same source tree as trace-cmd, we have
to place the 'top' meson.builld file under lib but we can't reference
it from the root meson.build which controlling the main trace-cmd
build.
This implies we can't access resources/path which are not below the
library's main meson.build directly. Thus, to be able to build the
documentation we have to use the symlink as workaround.
Link: https://lore.kernel.org/linux-trace-devel/20230208091204.7443-2-dwagner@suse.de
Signed-off-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
valgrind triggers its reports when the application exits. If the application
does a fork() and the child exits, it will still trigger a report saying that
the memory that was currently allocated by the parent has leaked.
To prevent this, call execl() on a shell script that will simply exit with the
proper error code. This will keep valgrind from producing a report on the
child for the memory that is still allocated by the parent.
Link: https://lore.kernel.org/linux-trace-devel/20230607140153.161b43a0@gandalf.local.home
Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The unit tests opens a handle via tracecmd_open() but fails to close it
causing the memory leak detector to trigger on it.
Link: https://lore.kernel.org/linux-trace-devel/20230607132710.4f642c78@gandalf.local.home
Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
While running valgrind to test the new attach command, it discovered that
the follow strings in the handle were never freed. Free them.
Link: https://lore.kernel.org/linux-trace-devel/20230606212750.1abd4a1d@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Having an automated test for memory problems is a useful functionality.
Combined with the trace-cmd unit test, it can be used to detect any
memory issues in the application. New Makefile target is added, which
runs the trace-cmd unit test on valgrind, to check for memory allocation
errors.
Link: https://lore.kernel.org/linux-trace-devel/20230607120202.86447-1-tz.stoyanov@gmail.com
Signed-off-by: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
With the addition of a new trace-cmd command attach, we need to up the
version to the "dev" release.
The library has some new APIs as well, so update that one too.
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a new trace-cmd command called "attach". This will attach a trace.dat
file created on a guest to a trace.dat file created on the host at the
same time. In some cases, trace-cmd agent isn't possible. This gives the
ability to do a trace on the guest with trace-cmd record, and on the host
as well, and then combine the two such that the guest events are
interleaved properly within the host events.
There's some requirements for the traces. The host side needs to enable
kvm_exit/entry events as well as to use the tsc2nsec clock. The guest
needs to use the x86-tsc clock.
As can be seen by the above requirements, this currently works only for
x86, but when other architectures have raw clocks that can do the same,
then they will be supported.
Link: https://lore.kernel.org/linux-trace-devel/20230606211658.580d3063@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add tracecmd_get_tsc2nsec() to be able to extract the multiplier, shift
and offset used to calculate the nanoseconds from the raw timestamp.
Link: https://lore.kernel.org/linux-trace-devel/20230606184526.7d7a48e4@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The tracecmd_iterate_events() and tracecmd_iterate_events_multi() uses
tracecmd_peek_data() to look at the next record. But when this is done,
the record is "cached" and "locked" in the handle. Which means they can
not be freed.
At the end of the iterators, make sure to read the data to unlock them,
and then free them.
Link: https://lore.kernel.org/linux-trace-devel/20230606145231.77820ea6@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The trace-cmd agent -h message does not specify that an IP needs to be
given as an argument. Update the help message to reflect that.
Link: https://lore.kernel.org/linux-trace-devel/20230602040955.6195a184@rorschach.local.home
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216291
Reported-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The error path only happens after the instance has been allocated. No need
to check if it exists again.
Link: https://lore.kernel.org/linux-trace-devel/20230602040123.3ce83b19@rorschach.local.home
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217128
Reported-by: Markus Elfring <Markus.Elfring@web.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The failure of allocating buf_to returns without freeing buf_from.
Link: https://lore.kernel.org/linux-trace-devel/20230602035815.43904076@rorschach.local.home
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217127
Reported-by: Markus Elfring <Markus.Elfring@web.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The string section description in the trace.dat v7 man page is a little
confusing. It is missing its section id, and so is the buffer text
section. Add the ids and clear up the description slightly.
Link: https://lore.kernel.org/linux-trace-devel/20230602033726.3c0ac34a@rorschach.local.home
Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217351
Reported-by: Douglas RAILLARD <douglas.raillard@arm.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Do not destroy an instance that already exists when trace-cmd record or
extract is executed. There may be state that the user still would like to
know about the instance. When doing an extract, it should not delete the
instance when it is finished.
Link: https://lore.kernel.org/linux-trace-devel/20230601082836.2fc2eb1b@rorschach.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The trace-cmd extract man pages explicitly states that if the '-B'
option is used, it will only extract the given instance and not touch
any other buffer instance including the top level, unless '-t' is given
(for the top level) or '-a' (for all instances). But currently it is
hard coded to extract the top level. Make extract only touch what it is
told according to the documentation.
Link: https://lore.kernel.org/linux-trace-devel/20230601075053.3fa7dd9b@rorschach.local.home
Reported-by: Douglas RAILLARD <douglas.raillard@arm.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217340
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The amount written to the file returned by tracecmd_compress_copy_from()
is off by 4 bytes. This is because it did not account for the writing of
the number of chunks saved.
Instead of calculating the amount written to the file, as lseek() is used to
find the chunk value and also put it back to the end of what was written,
use the results of lseek() to figure out the amount written.
It appears that the decompression of the sections did not use the size of
the buffer section, but instead used the size inside each chunk. That is,
it read the chunks within the buffer section and based what it would read
from the file by the size of each chunk, and did not use the value defined
in the section header.
Link: https://lore.kernel.org/linux-trace-devel/20230531055401.1f04a9fd@rorschach.local.home
Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
Reported-by: Douglas Raillard <douglas.raillard@arm.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217367
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Document how filters provided before any input files are global while
filters coming after a -i only apply to that filter.
Link: https://lore.kernel.org/linux-trace-devel/20230330185211.5604-4-krisman@suse.de
Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When a filter is provided before an input file, consider it globally
applying to all traces:
i.e., the following will trace kernel_stack out of both traces instead
of only the first:
$ trace-cmd report -v -F kernel_stack -i trace1.dat -i trace2.dat
Filter order matters due to the order of processing. Always process
global filters first, which are likely more generic.
Link: https://lore.kernel.org/linux-trace-devel/20230330185211.5604-3-krisman@suse.de
Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Since 955d05fc7aee ("trace-cmd report: Make filter arguments match their
files"), the -F filtering is silently ignored when a trace file is
provided with -i and the filter comes after -i . The reason is that the
filter is now associated with input_files and not saved to the global
list only in this case, but process_filters still only checks the global
list when handles->input_file is not set.
Avoid this by checking last_input_file first, which always contains a
pointer to the correct filter in this case.
Link: https://lore.kernel.org/linux-trace-devel/20230330185211.5604-2-krisman@suse.de
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217038
Fixes: 955d05fc7aee ("trace-cmd report: Make filter arguments match their files")
Signed-off-by: Gabriel krisman Bertazi <krisman@suse.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
In tracecmd/trace-record.c:<run_cmd>, trace-cmd record -F <executable>
is launched via the libc's execvp() routine. The way that execvp() routine
works is by invoking execve syscall for every entry on the $PATH if
command specified is neither absolute nor relative which can come across
as a bit cryptic to untrained eyes.
- absolute path example:
# trace-cmd record -p function_graph \
-g __x64_sys_execve -O nofuncgraph-irqs \
-n __cond_resched --max-graph-depth 1 \
-F /usr/bin/echo "ftrace" > /dev/null
# trace-cmd report
echo-172994 [000] 185539.798539: funcgraph_entry: ! 803.376 us | __x64_sys_execve();
- PATH-dependent path example:
# trace-cmd record -p function_graph \
-g __x64_sys_execve -O nofuncgraph-irqs \
-n __cond_resched --max-graph-depth 1 \
-F echo "ftrace" > /dev/null
# trace-cmd report
echo-172656 [002] 185009.671586: funcgraph_entry: ! 288.732 us | __x64_sys_execve();
echo-172656 [002] 185009.671879: funcgraph_entry: ! 158.337 us | __x64_sys_execve();
echo-172656 [002] 185009.672042: funcgraph_entry: ! 161.843 us | __x64_sys_execve();
echo-172656 [002] 185009.672207: funcgraph_entry: ! 157.656 us | __x64_sys_execve();
echo-172656 [002] 185009.672369: funcgraph_entry: ! 156.343 us | __x64_sys_execve();
echo-172656 [002] 185009.672529: funcgraph_entry: ! 863.629 us | __x64_sys_execve();
Open code the libc's execvp routine into trace-cmd so ftrace will only
start recording once the command is found when it needs to be found in
PATH.
Link: https://lore.kernel.org/linux-trace-devel/Y8yVDI93geYhLQio@mail.google.com
Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Its no longer needed since we have dropped using LF64 interfaces
Link: https://lore.kernel.org/linux-trace-devel/20230109225315.1284538-2-raj.khem@gmail.com
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Musl does not define these interfaces unless -D_LARGEFILE64_SOURCE is
defined and that too it is transitional until apps switch to using 64-bit
off_t. We pass -D_FILE_OFFSET_BITS=64 in makefiles already therefore
original lseek and off_t are already 64bit
This fixes build with latest musl which has dropped LFS64 interfaces [1]
[1] https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4i
Link: https://lore.kernel.org/linux-trace-devel/20230109225315.1284538-1-raj.khem@gmail.com
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The tracecmd_stop_recording() is suppose to force the recorders to finish,
but because it is called from a signal handler, that may not necessarily be
the case (due to race conditions and such). Set an alarm to try again in a
second, then after two seconds, and then three, and so on.
Link: https://lore.kernel.org/linux-trace-devel/20230106183930.12565-11-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When the recording (of trace-cmd record) or streaming (of trace-cmd stream)
is finished, set sleep_time to zero. This will cause various calls to read
the buffer to not block, as the sleep_time is used in some instances to
determine how long to wait if there's no data.
Link: https://lore.kernel.org/linux-trace-devel/20230106183930.12565-10-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Ideally, tracefs_cpu_stop() is suppose to return zero if it guaranteed to
stop the recorders (but this may not be true if called from a signal
handler). Return the result of tracefs_cpu_stop() in
tracecmd_stop_recording().
Link: https://lore.kernel.org/linux-trace-devel/20230106183930.12565-9-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When in streaming mode, set the default to half a second instead of 1
millisecond (which should be changed for record as well).
Link: https://lore.kernel.org/linux-trace-devel/20230106183930.12565-8-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Replace the select() that is used in trace_stream_read() with poll() as that
is the more robust function, as select() is limited to fds that are less than
1024, and today's kernels can have fds bigger than that.
As a side-effect, since poll() uses milliseconds for its timeout, the
granularity of the timeout is no longer microseconds, even though that is
what is passed in on the command line. We may need to changes this.
If 1us is passed in, it will be rounded up to 1ms. But zero and negative
numbers shall remain the same.
Link: https://lore.kernel.org/linux-trace-devel/20230106183930.12565-7-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If tracefs_cpu_read() has an error, it will return a negative value. But the
value is then used as an index. An error check is required to make sure that
if an error is returned from tracefs_cpu_read() the function exits with that
error and does not continue further.
Link: https://lore.kernel.org/linux-trace-devel/20230106183930.12565-6-rostedt@goodmis.org
Fixes: 2610bdcde ("trace-cmd library: Use tracefs_cpu for recorder helpers")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When trace-cmd stream is finished, the trace_or_sleep() will exit before
waiting for the pipes to flush. Call trace_stream_read() one more time, and
with indefinite blocking, as the pipes should finish everything and then
close (which will stop the polling).
Link: https://lore.kernel.org/linux-trace-devel/20230106183930.12565-5-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Have trace-cmd stream periodically signal the recorder tasks to flush some
output, otherwise it will look empty for a long time (especially with the
default setting of a 50 percent buffering, where the ring buffers will not
return read until they are half full).
Add a "finish" flag to tracecmd_flush_recording() that will keep the old
behavior when set, but when not set, it will only do a single
tracefs_cpu_flush() that will output some data, but not all of it.
Use the SIGUSR2 to signal the recorder tasks to do the flush.
Link: https://lore.kernel.org/linux-trace-devel/20230106183930.12565-4-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When the trace-cmd stream is exiting, it flushes the data. But it does so in
a blocking way, where it can block when there's nothing to read. Set the
timeout of trace_stream_read() to zero in order to return immediately.
Link: https://lore.kernel.org/linux-trace-devel/20230106183930.12565-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When the recorder is signaled to stop, make sure it only reads in
non-blocking mode.
Link: https://lore.kernel.org/linux-trace-devel/20230106183930.12565-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The trace_stream_init() function creates a temp file to save the headers
in, and then reads it for processing the information. It does this by
using tmpfile() to create the temp file, grabs the file descriptor from
it, and then calls tracecmd_output_create_fd() on it to save the
information. After it is written, the trace_output is no longer needed,
and the tracecmd_input descriptor is created by reading this temporary
file.
The problem arises with the movement of when the trace option are written.
As some options need to happen after recording, they are finished up at
the end where tracecmd_output_close() is called. But in this case, we only
want the options written, and not to close the descriptor (as it will be
used for reading too).
Create a new tracecmd_output_flush() that writes out the options and use
that.
Link: https://lore.kernel.org/linux-trace-devel/20230105135646.701f4138@gandalf.local.home
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216577
Reported-by: Charlemagne Lasse <charlemagnelasse@gmail.com>
Fixes: 5d4d7ec30255 ("trace-cmd: Move reading of trace.dat options to tracecmd_read_headers()")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Update the check-manpages.sh script to make sure that there are no
functions that are described in more than one man page.
Link: https://lore.kernel.org/linux-trace-devel/20230104172655.145516-2-rostedt@goodmis.org/
Link: https://lore.kernel.org/linux-trace-devel/20230104123722.00887044@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Existing cscope target using sh pipes was broken and cscope was throwing
the following error:
$ make cscope
[..]
cscope: no source files found
fix cscope target by writing files to be indexed into a separate file
called cscope.files which cscope reads by default
Link: https://lore.kernel.org/linux-trace-devel/Y7YRrHaV+V6v+9WZ@mail.google.com
Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Make 4.4 introduces several backward incompatibilities and the result
is that building trace-cmd with it never finishes. It seems that make
ends up in some kind of infinite recursion. The symptoms are:
$ make -d
GNU Make 4.4
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'Makefile'...
Makefile:79: not recursively expanding pkgconfig_dir to export to shell function
Makefile:79: not recursively expanding pkgconfig_dir to export to shell function
Makefile:224: not recursively expanding LIBTRACECMD_SHARED_VERSION to export to shell function
Makefile:79: not recursively expanding pkgconfig_dir to export to shell function
Makefile:224: not recursively expanding LIBTRACECMD_SHARED_VERSION to export to shell function
Makefile:225: not recursively expanding LIBTRACECMD_SHARED_SO to export to shell function
Makefile:79: not recursively expanding pkgconfig_dir to export to shell function
Makefile:79: not recursively expanding pkgconfig_dir to export to shell function
Build succeeds if recursively expanded variables (defined with '='),
which use $(shell ...) as its value, are replaced with simply expanded
variables (defined with ':=').
Link: https://lore.kernel.org/linux-trace-devel/20221226164951.2632069-1-michal.sojka@cvut.cz
Signed-off-by: Michal Sojka <michal.sojka@cvut.cz>
Tested-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
As stat() can overflow if a 32 bit user space reads a file on a file
system that has inodes greater than MAX_INT. Compile with
_FILE_OFFSET_BITS=64 that mitigates this problem on 32 bit user space.
Link: https://lore.kernel.org/linux-trace-devel/20221221135154.427ad9f4@gandalf.local.home
Reported-by: Mike Frysinger <vapier@google.com>
Tested-by: Ross Zwisler <zwisler@google.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The read max test checks the stats by running trace-cmd report --stat on
the file. The problem is that it left out the output file that was
created, and if the default file trace.dat does not exist, it fails to
read it. Unfortunately, if it does exist, it may give a false pass or
fail.
Link: https://lore.kernel.org/linux-trace-devel/20221210205328.1f1f03ce@gandalf.local.home
Fixes: 1f75010a2 ("trace-cmd: Add test for max size option of record")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Let the convert subcommand compress automatically if the file format
allows it and the user did not specify it.
This already the case the record command.
Link: https://lore.kernel.org/linux-trace-devel/Y5Tt6p0ONpuDVIS2@breakpoint.cc
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Use the API from libtracefs on tracefs_cpu that is used for reading from
the trace_pipe_raw files for the recorder.
Link: https://lore.kernel.org/linux-trace-devel/20221115154848.21fc8698@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a unit test to test the trace-cmd record -m X option.
Link: https://lore.kernel.org/linux-trace-devel/20221115205355.2580214-5-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
To make the grep and pipe functions in the unit test more flexible,
separate them out and instead of passing in the arguments and using
va_list directly, pass in a void pointer and use as structure to pass in
the arguments. This will allow for extending the grep and pipe functions
to use different type of arguments as well as functionality.
Link: https://lore.kernel.org/linux-trace-devel/20221115205355.2580214-4-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The "Use libraries to read file" test shows the output of the reading of
the trace.dat file. That should only happen if the '-v' option is
supplied, otherwise, it should be muted.
Link: https://lore.kernel.org/linux-trace-devel/20221115205355.2580214-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Several times I've been confused that the unit test was not working after
I had fixed some of the library code. The reason is that the unit test
binary does not have a dependency on the static library. Even though the
library is updated, the unit test will not reflect the changes because it
was not rebuilt against the updated static library.
Add a dependency to the static library to the unit test binary.
Link: https://lore.kernel.org/linux-trace-devel/20221115205355.2580214-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The -m option limits the size of each per-cpu buffer to the value
specified in kbs (or actually pages). That is, if -m 1000 is specified,
then the size per cpu buffer should not be more that 1000 kbs. Since it is
implemented in halfs, it is usually between half and the full amount.
But since the buffer reads can use pipes, the increment of the page count
needs to take that into consideration. Currently, it just increments the
page count every time the count goes over the page size. But due to pipes,
the size increment can be multiple pages (65k in fact), and this distorts
the size.
Have the page count increment via the actually size read and not just by
one even if several pages were read at one go.
Link: https://lore.kernel.org/linux-trace-devel/20221115153502.5253871c@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Set the default loglevel to TEP_LOG_ERROR, as TEP_LOG_WARNING is adds a
lot of noise.
Link: https://lore.kernel.org/linux-trace-devel/20221110022341.7a719ec3@rorschach.local.home
Fixes: 51ae62947 ("trace-cmd library: Only set trace-cmd log level")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The function graph plugin will look at the next event and may even
increment it if it is a leaf function. The current iterators update the
next record before the callback. This leaves them vulnerable to
corruption if the callback updates to the next record like function
graph plugin does.
Peek at the next record after the callback to ensure that the next
record is the one that will be used for the next iterator.
Link: https://lore.kernel.org/linux-trace-devel/20221110003325.007663c7@rorschach.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add 256 to the size of cmd[] and xml[] to quiet the warnings:
trace-setup-guest.c: In function ‘attach_guest_fifos’:
trace-setup-guest.c:247:1: warning: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4058 [-Wformat-truncation=]
134 | snprintf(xml, sizeof(xml), xml_fmt, path, GUEST_PIPE_NAME, i);
| ~~~~
......
247 | }
| ^
trace-setup-guest.c:247:1: note: directive argument in the range [0, 2147483646]
trace-setup-guest.c:134:17: note: ‘snprintf’ output between 102 and 4206 bytes into a destination of size 4096
134 | snprintf(xml, sizeof(xml), xml_fmt, path, GUEST_PIPE_NAME, i);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
trace-setup-guest.c:247:1: warning: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4063 [-Wformat-truncation=]
137 | snprintf(cmd, sizeof(cmd), cmd_fmt, guest, tmp_path);
| ~~~~~~~~
......
247 | }
| ^
trace-setup-guest.c:137:17: note: ‘snprintf’ output 58 or more bytes (assuming 4153) into a destination of size 4096
137 | snprintf(cmd, sizeof(cmd), cmd_fmt, guest, tmp_path);
Link: https://lore.kernel.org/linux-trace-devel/20221109183204.33ae109d@rorschach.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add missing header file to make it compile with musl C library.
Link: https://lore.kernel.org/linux-trace-devel/20221101105803.191324-1-peter@berginkonsult.se
Signed-off-by: Peter Bergin <peter@berginkonsult.se>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add the function tracecmd_follow_missed_events() to let applications add
a hook for when any events are missed. The callback will be called even
if filtering is enabled.
Link: https://lore.kernel.org/linux-trace-devel/20221106144441.1fb08fd5@rorschach.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The callbacks path can possibly be called when the next record is NULL. Do
not call the callbacks in this case, as they are not expecting a NULL
record, nor should they have to.
Move the code that calls the callbacks in tracecmd_iterate_events() and
tracecmd_iterate_events_multi() into a single helper function to alleviate
fixing one and not the other.
Link: https://lore.kernel.org/linux-trace-devel/20221007143859.6895d756@gandalf.local.home
Reported-by: Ian Rogers <irogers@google.com>
Fixes: 3cd1b55f3 ("trace-cmd library: Add tracecmd_follow_event()")
Fixes: 82ed4a937 ("trace-cmd library: Add filtering logic for iterating events")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Have tracecmd_set_loglevel() only for trace-cmd and not touch libtracefs
and libtraceevent log levels. Let the application handle this instead.
Update the trace-cmd code to keep the same reporting.
Move the updates of libtracefs and libtraceevent log levels from the
library into the application.
Link: https://lore.kernel.org/linux-trace-devel/20221006190621.46bbb606@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
For some reason, I thought the arg to fcntl(fd, F_GETPIPE_SZ, &arg) would
give the pipe size. But the argument is completely ignored (I remember
testing this, and it worked :-/)
The return of the function is the pipe size. Use that if pipe_size is
untouched (which it ought to be) as the pipe size.
Link: https://lore.kernel.org/linux-trace-devel/20220928095753.54b6621c@gandalf.local.home
Fixes: a64fab23cec2 ("trace-cmd recorder: Use full pipe size in splice_data()")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
After writing a few applications to analyze host guest interactions, I
found that I was writing the same code. Instead, add helper functions to
do the mapping.
tracecmd_map_vcpus()
tracecmd_get_cpu_map()
tracecmd_map_find_by_host_pid()
tracecmd_cpu_map()
tracecmd_map_get_host_pid()
tracecmd_map_get_guest()
tracecmd_map_set_private()
tracecmd_map_set_private()
Link: https://lore.kernel.org/linux-trace-devel/20220922174847.30475299@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
This is already supported and works as expected; allow the option to be
specified.
Link: https://lore.kernel.org/linux-trace-devel/20220901205638.3247090-1-zfigura@codeweavers.com
Signed-off-by: Zeb Figura <zfigura@codeweavers.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Starting with libtraceevent 1.6.2, the kvm plugin will call a weak
function that can be overridden by the application (in this case
trace-cmd) called tep_plugin_kvm_get_func() that passes in the event, the
record, and an address to a value containing the address of the function
being requested. If the application has the guest mapping of addresses to
function names (usually taken from kallsyms), then it can define this
function to return the name of the function at the given address of the
guest.
Optionally, it can update the value holding the address, to the start of
the function such that the tep kvm plugin can print not only the function
name, but also the address offset of the original location and the
function itself.
Link: https://lore.kernel.org/linux-trace-devel/20220921202642.44fec719@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add man pages for the following iterator functions:
tracecmd_iterate_events()
tracecmd_iterate_events_multi()
tracecmd_follow_event()
tracecmd_filter_add()
Link: https://lore.kernel.org/linux-trace-devel/20220922013737.3302850-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add the tracecmd_follow_event() to make it easier for applications to
have a callback for specific events when calling either
tracecmd_iterate_events() or tracecmd_iterate_events_multi()
Link: https://lore.kernel.org/linux-trace-devel/20220922013737.3302850-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The tracecmd_set_private() and tracecmd_get_private() functions were not
in the man pages. Add them, and also add a working example for the
tracecmd_open() (and other) function.
Link: https://lore.kernel.org/linux-trace-devel/20220922002940.3302285-6-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add to the man pages the function tracecmd_get_first_ts(), and
tracecmd_add_ts_offset().
Link: https://lore.kernel.org/linux-trace-devel/20220922002940.3302285-5-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add the script check-manpages.sh that makes sure all the function that
are documented in the man pages are show in the overall man page
"libtracecmd" as well as making sure that all functions in
trace-cmd.h is also documented.
Link: https://lore.kernel.org/linux-trace-devel/20220922002940.3302285-4-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The function tracecmd_filter_match() is really an internal function. It
should not be exported for other applications (The trace-cmd core
functions do not use it). It should definitely not be in the public
headers.
Move the prototype so that it is only used internally within the
library.
Link: https://lore.kernel.org/linux-trace-devel/20220922002940.3302285-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Functions referenced in man pages should be bold and not underscored.
Convert all function references in the man pages to be bold.
Link: https://lore.kernel.org/linux-trace-devel/20220922002940.3302285-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The function trace_get_guest() will first look for a guest by name, and
if it finds one, it will return it. But if the guest added did not have
a name (but had an empty string), it would return any guest that also
did not have a name (but just an empty string). If two guests did not
have a name, and the CID was used, then the first guest would be
returned for the second guest, breaking the creating of two guests where
both were without names.
Link: https://lore.kernel.org/linux-trace-devel/20220922002348.3302169-4-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
In trace_vsock_open(), if the connection fails, the sd file descriptor
still needs to be closed.
Link: https://lore.kernel.org/linux-trace-devel/20220922002348.3302169-3-rostedt@goodmis.org
Fixes: 76aaeb474 ("trace-cmd: Add VM kernel tracing over vsockets transport")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add an option to not timeout, but will still fork. This is for using
with gdb on one end, and have the other end using the notimeout option,
but still doing the forking and other code that --debug disables on the
other end.
Link: https://lore.kernel.org/linux-trace-devel/20220922002348.3302169-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Continuing in the ld.lld link issues trace-cmd needs to override
-lrt -lpthread and -ldl. This adds the ability, from the command line,
adjust LIBS, LRT and LPTHREAD
Link: https://lore.kernel.org/linux-trace-devel/20220826225904.1824344-1-warthog9@eaglescrag.net
Signed-off-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
This might be obvious but it still took me some Makefile reading. Add it
to README to make it easier for others.
Link: https://lore.kernel.org/linux-trace-devel/20220815031342.775201-2-joel@joelfernandes.org
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Linking in C++ compilers (including g++) causes references to be created
with their arguments. Due to this, trace library headers included into
C++ code base will cause their objects to built with symbols with
arguments. Apparently this is to support operator overloading in C++.
This causes linker errors. For example, here's what I get when I try to
link libtracecmd with a main.o built from a C++ main.cc source file.
main.cc:(.text+0x90):
undefined reference to `tracecmd_get_tep(tracecmd_input*)'
undefined reference to `tracecmd_free_record(tep_record*)'
undefined reference to `tracecmd_read_data(tracecmd_input*, int)'
The standard fix for this is to wrap the C project's header in
extern "C".
With this patch, I am able to link libtracecmd into a C++
code base.
Link: https://lore.kernel.org/linux-trace-devel/20220815031342.775201-1-joel@joelfernandes.org
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Other Linux kernel tools like perf already include options to disable
libzstd manually. Add this option also to trace-cmd.
The OpenWrt SDK fails to build trace-cmd due to the autodetection of
libzstd. The package is present in some feed repositories but should
not be used by trace-cmd. The compilation will fail with:
Package trace-cmd is missing dependencies for the following libraries:
libzstd.so.1
Link: https://github.com/rostedt/trace-cmd/pull/19
Signed-off-by: Nick Hainke <vincent@systemli.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Simplify trace-read.c by implementing the use of tracecmd_filter_add(),
tracecmd_filter_match(). And move the processing into the library.
Link: https://lore.kernel.org/linux-trace-devel/20220805154040.2014381-10-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Currently the filter argument "-F" only affects the first file passed in,
and is ignored for the rest of the files passed in via '-i'. Also, buffers
ignore them as well.
Have the -F affect the last '-i file', with the exception that the -F
filter can be called before the first file. That is, the first -i file is
affected by any -F before it and directly after it but before another -i
file is added.
Also, have buffers within a file be affected by the filters given to the
file.
Link: https://lore.kernel.org/linux-trace-devel/20220805154040.2014381-9-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add tracecmd_filter_add() and tracecmd_filter_match() for filtering of
events during tracecmd_iterate_events() and
tracecmd_iterate_events_multi().
Link: https://lore.kernel.org/linux-trace-devel/20220805154040.2014381-8-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Use the new helper library function tracecmd_iterate_events_multi(). This
simplifies the code as well as shows an example of how to use it for other
applications.
Link: https://lore.kernel.org/linux-trace-devel/20220805154040.2014381-7-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a private field for tracecmd_input handle where callers can set it via
tracecmd_set_private() and retrieve it with tracecmd_get_private(). This
will allow a way to find specific information about a handle for users of
tracecmd_iterate_events_multi().
Link: https://lore.kernel.org/linux-trace-devel/20220805154040.2014381-6-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a helper function that takes an array of tracecmd_input handles and
calls the callback for each event in order of the record's timestamp for
each handle.
Link: https://lore.kernel.org/linux-trace-devel/20220805154040.2014381-5-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a test that uses tracecmd_open() and tracecmd_iterate_events() to read
a trace.dat file.
Link: https://lore.kernel.org/linux-trace-devel/20220805154040.2014381-4-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a helper function that will iterate over a list of events for a given
handle. Requires the handle to be opened and ready for reading.
Link: https://lore.kernel.org/linux-trace-devel/20220805154040.2014381-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Instead of adding a test in all the Makefiles that test ZLIB_INSTALLED,
just create a variable that has ZLIB_LDLAGS set to -lz when enabled and
pass that to the LIB flags. When it's not enabled, ZLIB_LDLAGS will be
empty.
(I guess LDLAGS should have been LDFLAGS but a typo appears to have gone
wild!)
Link: https://lore.kernel.org/linux-trace-devel/20220805154040.2014381-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The agent "-P" and the record "--proxy" options that were added did not
get documented in either the man pages nor the usage output. Add the
necessary documentation for them.
Link: https://lore.kernel.org/linux-trace-devel/20220804103729.1.Ia9701619f867f6acbec9e20bf89ed41979fcce87@changeid
Fixes: 4f9d216ee312 ("trace-cmd: Add agent proxy communications between record and agent")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If an agent (-A) is specified before a --proxy option, then the proxy
option will be passed to the agent, which should not be done. Keep that
from happening.
Link: https://lore.kernel.org/linux-trace-devel/20220729164940.233652b0@rorschach.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If there are no parameters passed to the guest agent, then the loop
inside tracecmd_msg_read_data() will not iterate and the msg variable
will be accessed (freed) without being initailized causing a possible
SEGFAULT.
Link: https://lore.kernel.org/linux-trace-devel/20220729164850.460886bb@rorschach.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When trace-cmd initiates a connection to a trace agent over the network,
the logic in connect_to_agent() function incorrectly uses the last
instance saved in the trace context, instead of the actual instance
which is passed as input argument. This works if the remote agent is
set last on the command line, but causes a problem if there is more than
one agent or if there is a local buffer after the agent on the command
line.
Link: https://lore.kernel.org/linux-trace-devel/20220729040116.175015-1-tz.stoyanov@gmail.com
Reported-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
Tested-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Instead of hard coding CFLAGS to be "-g -Wall", have that be the default,
but if the user adds their own CFLAGS, it will override that.
Link: https://lore.kernel.org/linux-trace-devel/20220711152356.65790b1b@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
pointer in struct tracecmd_compression is 'unsigned long', which is 8 byte
in size on most platforms, but the tep_read_number() call in the next line
treats it as a 4 byte value. As there's no need for unsigned long change
the type to unsigned int.
Link: https://lore.kernel.org/all/20220711074418.858843-1-svens@linux.ibm.com/
Link: https://lore.kernel.org/all/20220711094340.2829115-1-svens@linux.ibm.com/
Link: https://lore.kernel.org/linux-trace-devel/20220711142104.090b9030@gandalf.local.home
Fixes: 3f8447b1 ("trace-cmd library: Add support for compression algorithms")
Acked-by: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If the kvm vcpuX files do not map directly to the guest's CPUs, then the
tmaps will not match and the host will not have a mapping to the guest.
That is, if the hypervisor has:
# ls -d /sys/kernel/debug/kvm/[0-9]*/vcpu*
/sys/kernel/debug/kvm/408-7/vcpu0 /sys/kernel/debug/kvm/408-7/vcpu24
/sys/kernel/debug/kvm/408-7/vcpu1 /sys/kernel/debug/kvm/408-7/vcpu26
/sys/kernel/debug/kvm/408-7/vcpu16 /sys/kernel/debug/kvm/408-7/vcpu28
/sys/kernel/debug/kvm/408-7/vcpu18 /sys/kernel/debug/kvm/408-7/vcpu30
/sys/kernel/debug/kvm/408-7/vcpu20 /sys/kernel/debug/kvm/408-7/vcpu8
/sys/kernel/debug/kvm/408-7/vcpu22 /sys/kernel/debug/kvm/408-7/vcpu9
But the guest sees CPUs 0-11, the kvm exit/enter events will also show the
above numbers (vcpu 8 for guest CPU 3).
Have the mapping logic look at these files and sort them, and then map the
threads to CPU via them.
Link: https://lore.kernel.org/linux-trace-devel/20220708014244.677826-3-rostedt@goodmis.org
Link: https://lore.kernel.org/all/20220504010242.1388192-1-vineethrp@google.com/
Reported-by: Vineeth Pillai <vineethrp@google.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
There are some setups where the vcpu directories in:
/sys/kernel/debug/kvm/<pid>/vcpuX
Does not match the CPU of the guest. That is, the guest CPU 3 may be
vcpu8.
This breaks the algorithm used when setting up the kvm time
synchronization. As it expects these files to map to the CPU used, and if
one of the vcpuX is greater than the number of CPUs of the guest, it will
fail.
Currently, the locations that do this at least have the guest CPUS
consecutive (non sparse) and they map to the kvm vcpuX in order. That is,
if the vcpuX is sorted by the X it will then map to the CPUs of the guest.
This may not hold true for all setups, but we are currently just going to
solve this one. It appears that the vcpuX in kvm maps to the guest's
apicid in /proc/cpuinfo. More can be done later to make sure the two are
in order and if not to put in meta data that will allow the kvm mappings
to still work.
For now restructure the code by creating a single kvm_clock_files
structure to hold the offset, scaling and frac arrays in a single
structure, and also add the vcpu to it when adding new information from
the vcpuX directories. Then sort the list by the vcpu such that it should
map to the 0-nr_cpus of the guest.
Link: https://lore.kernel.org/linux-trace-devel/20220708014244.677826-2-rostedt@goodmis.org
Link: https://lore.kernel.org/all/20220504010242.1388192-1-vineethrp@google.com/
Reported-by: Vineeth Pillai <vineethrp@google.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If the clock_context_init() fails, the ctx->instance->tsync will be NULL,
but it may be used in calling tracecmd_write_guest_time_shift(). This will
cause a SEGFAULT as that function expects it to be non NULL.
Test for tsync not NULL and return -1 if it is.
More should be done to warn when this happens, but for now prevent the
SEGFAULT. This makes the code more robust.
Link: https://lore.kernel.org/linux-trace-devel/20220707191621.77deba71@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If the clock_context_init() fails, it can cause the communications between
the host and guest to hang without any clue to why it happened. I spent
several hours debugging this.
There's no reason that the clock_context_init() needs to be called in the
pthread. Do that before creating the threads, and move the proto into the
tsync structure itself.
Now when it fails, more can be known at the time it happens.
Link: https://lore.kernel.org/linux-trace-devel/20220707190726.3f1c6b4d@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Paragraph "Format of Section Header" states to write the size of a section
on 4 bytes, but the actual size is 8 bytes (long long unsigned int).
Link: https://lore.kernel.org/linux-trace-devel/20220629161845.2432-1-matteo.bertolino@huawei.com
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216185
Signed-off-by: Matteo Bertolino (Huawei Technologies France) <matteo.bertolino@huawei.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a unit test that tests the conversion of trace-cmd 7 to trace-cmd 6.
This also adds infrastructure to do a grep of the output of trace-cmd.
Link: https://lore.kernel.org/linux-trace-devel/20220616153001.649858-5-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a simple test that does a trace-cmd record of schedule events and then
reads it with trace-cmd report. This also adds some infrastructure to make
it easy to run trace-cmd commands.
Link: https://lore.kernel.org/linux-trace-devel/20220616153001.649858-4-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Now that the unit tests will be testing trace-cmd and not libtracefs,
rename the file to reflect that.
Link: https://lore.kernel.org/linux-trace-devel/20220616153001.649858-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The unit tests in trace-cmd are all for libtracefs, and those tests are in
the libtracefs repo. There's no reason to keep them here. Instead remove
them all and start a template to add trace-cmd specific tests.
The initialization phase is just finding the in tree trace-cmd code.
Link: https://lore.kernel.org/linux-trace-devel/20220616153001.649858-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a test to make sure that splice works on the source directory before
using it, and if not automatically switch over to read/write method.
Link: https://lore.kernel.org/linux-trace-devel/20220615190653.559ad605@gandalf.local.home
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=213659
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When not using read_zpage, and reading from a temporary file, the offsets
are not accounted for properly. That is, it uses the offset of the
location of the trace.dat file to map the temporary file (that starts at
offset zero).
Account for mapping of the temporary file when appropriate.
Link: https://lore.kernel.org/linux-trace-devel/20220615025436.568682-3-rostedt@goodmis.org
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Fixes: add83e0c8b51 ("trace-cmd library: Fix tracecmd_read_at()")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If the initialization of tracecmd_init_data() fails, the processing will
continue and this can cause errors latter on that are unrelated to the
actual problem. Fail immediately instead.
Link: https://lore.kernel.org/linux-trace-devel/20220615025436.568682-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
List the synthetic events that are defined.
Link: https://lore.kernel.org/linux-trace-devel/20220608163152.425352-4-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
List the PIDs that are not to be traced by the function tracers that are
listed in the set_ftrace_notrace_pid.
Link: https://lore.kernel.org/linux-trace-devel/20220608163152.425352-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Have trace-cmd stat list the PIDs that are in the set_event_notrace_pid.
Link: https://lore.kernel.org/linux-trace-devel/20220608163152.425352-2-rostedt@goodmis.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208813
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If the file that is being split has missed events, the new file does not
create them. This gets confusing for users that see gaps in the trace.
Have the split code preserve the missed events in the new file.
Link: https://lore.kernel.org/linux-trace-devel/20220608111424.4a66d384@gandalf.local.home
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212421
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
For tracecmd_read_at() to work, each offset for every record in the file
needs to be unique. To do so, each CPU's file_offset is from the last
CPU's file_offset plus its size. But the size used was the compressed size
and not the uncompressed size.
This had "interesting" effects, where some lookups were failing. It also
caused tracecmd_read_cpu_last() to not return the last event.
Link: https://lore.kernel.org/linux-trace-devel/20220608105243.7eef6394@gandalf.local.home
Fixes: add83e0c8b511 ("trace-cmd library: Fix tracecmd_read_at()")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The binary search looking for an address in the compressed chunks was
failing when it should have found a chunk. The reason is that the order of
the offsets is in ascending order, but the search was looking as if it was
in descending order.
Link: https://lore.kernel.org/linux-trace-devel/20220608104806.27edb40b@gandalf.local.home
Fixes: 6a724f21bbbe1 ("trace-cmd library: Add logic for in-memory decompression")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The way the files are printed in trace-cmd stat uses a read loop and keeps
allocating memory to read the content. It reads at BUFSIZ increments. But
if a read does not read exactly BUFSIZ it stops reading and returns what
it read but may not return the rest.
This does not work with the filter functions as the read may not fill the
buffer (it does not return an unfinished function). This makes the loop
exit early.
Instead just increase with BUFSIZ against what was allocated and comparing
to the total.
The way to trigger the issue is by:
# trace-cmd start -p nop -l "*"
# trace-cmd show --ftrace_filter |wc -l
50979
# trace-cmd stat | wc -l
234
Link: https://lore.kernel.org/linux-trace-devel/20220607183142.00dac63f@gandalf.local.home
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212489
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a --temp option to trace-cmd record that lets the user specify where
the temporary files will be recorded to. Instead of using the location of
the trace.dat file to store the temporary files that are recorded by
splice, they are recorded in the directory specified by --temp.
Link: https://lore.kernel.org/linux-trace-devel/20220607163334.289f2e41@gandalf.local.home
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=213661
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The '-l' option shows latency information of each event. It is not well
documented. Update the man page to show what the cryptic values mean.
Link: https://lore.kernel.org/linux-trace-devel/20220607122857.2dd8b761@gandalf.local.home
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216069
Reported-by: Julia Lawall <julia.lawall@inria.fr>
Acked-by: Julia Lawall <julia.lawall@inria.fr>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The man page example code is only surrounded by dashes, which worked in
the early days but now it shows:
.ft c
around the example if not the right packages are installed. Add the
"[source,<lang>]" attribute around them, and shorten the dashes to just
four. This allows the parsing to be better and the man page to be proper.
Link: https://lore.kernel.org/linux-trace-devel/20220608124832.12526bc3@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add the options to trace-cmd report to show the timestamp of the first and
last events.
This also fixes a memory leak when --cpus is used, but was not a major
issue as the code exited immediately afterward.
Link: https://lore.kernel.org/linux-trace-devel/20220607122242.51bf5aa2@gandalf.local.home
Suggested-by: Julia Lawall <julia.lawall@inria.fr>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216068
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If the time synchronization protocol for the recorder to a agent proxy is
KVM, then it means that the TSC clock must be used. Force it when this is
discovered.
Link: https://lore.kernel.org/linux-trace-devel/20220524015028.260238-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If the option TSC2NSECS is set, then display as microseconds like it does
with trace clock local. This is because even though the x86-tsc is not in
nanoseconds, the clock will be shifted and multiplied to be in
nanoseconds, so it makes sense to convert it to seconds.
Link: https://lore.kernel.org/linux-trace-devel/20220524015028.260238-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The KVM offset and multiplier are in the debugfs file system. If it is
not currently mounted, then try to mount it with the new tracefs API
tracefs_debug_dir() which will return the debugfs file system path, and
even mount it if possible (or NULL if it could not).
This also removes the hard coded path for /sys/kernel/debug/kvm and
removes the stat() of the directory as tracefs_debug_dir() will only
return mount locations which are directories.
Set libtracefs minimum version to 1.4 as that is what will have the
tarcefs_debug_dir() in it.
Link: https://lore.kernel.org/linux-trace-devel/20220522003935.196466-5-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When a guest uses trace-cmd record to connect to the agent proxy on the
host, it needs to set its role to "GUEST" when initializing the time
synchronization protocols.
Link: https://lore.kernel.org/linux-trace-devel/20220522003935.196466-4-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Currently if there are no valid VMs the kvm supported check can return
true. Check for at least one valid VM, and that echa VM has one valid
VCPU.
Also comment the code as it is very confusing to why the scaling checks
return true or false.
Link: https://lore.kernel.org/linux-trace-devel/20220522003935.196466-3-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
kvm_scaling_check_vm_cpu() uses read_ll_from_file() to determine if the
kvm scaling and fraction files exist. The read_ll_from_file() does not
return if the contents of the files are legit or not. No need to read
them in this file. Just use stat().
Link: https://lore.kernel.org/linux-trace-devel/20220522003935.196466-2-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If the agent is a proxy server (host), then it should not pick the kvm
protocol if it can not find the kvm offset and multiplier. If it does, it
will fail the sync on the agent side which locks up the recorder side
which will still run.
This also shows how fragile the tsync code is but that is another project
to have fixed.
Link: https://lore.kernel.org/linux-trace-devel/20220519204328.534a1f30@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
If an old trace-cmd only uses v1 in the listen communication, to determine
this a trick is done by passing the v1 CPU communication a -1 followed by
the communication version. V3 and beyond knows this as the version
communication number, but v1 will error out. Then the connection is closed
and v1 is tried anew. (Note, v2 never existed in a release so it can be ignored).
The problem is that on the retry, the host has been updated with via a
strchr(), and modified. The second time around, it will not have the port
number attached to it, so it will fail to communicate.
Link: https://lore.kernel.org/linux-trace-devel/20220521180844.2af85772@gandalf.local.home
Fixes: 194467199c076 ("trace-cmd listen: Add vsocket usage")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The time synchronization logic between agent and recorder made the
assumption that the host is running the recorder and the guest is
running the agent. This is very limiting, especially for environments
where you have a streamlined host that has no disk space, and a guest
that is "privileged".
Have the agent proxy handle the time synchronization for the host, and
the trace-cmd record running on the guest retrieve this information from
the host.
Link: https://lore.kernel.org/linux-trace-devel/20220514024756.1319681-27-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Have the guest structure hold the guest's trace_id and also use the guest
structure for the CPU counts in mapping the guest CPUs to pids. For the
agent proxy, the instance will be of the host and not the guest, so it
makes more sense to use the guest structure instead.
Also clean up the trace_add_guest_info() call where the network uses the
instance, and the cpus use the max cpus.
Link: https://lore.kernel.org/linux-trace-devel/20220514024756.1319681-26-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The host controls the time shift for the guest, and when the host is
running as an agent proxy, it must be able to send that data to the
guest to be saved it the guests file. But the guest running the recorder
does not create its file until the end of the trace.
Send options for the time shift at the end of the trace (will later add
the time synchronization too). The guest recorder will then add this to
its trace.dat file.
Link: https://lore.kernel.org/linux-trace-devel/20220514024756.1319681-25-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When the trace-cmd agent is passed the proxy flag "-P" with the guest
CID that it can talk to, add it to the list of guests, as it should be
able to find all the host tasks that control the guest.
Link: https://lore.kernel.org/linux-trace-devel/20220514024756.1319681-24-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The options of the agent proxy trace file will need to include timings
and guest data that is added after the trace has completed. Do not close
the network handle for the meta data before the trace. Keep it open for
the proxy agent and finish writing the options at the end of the trace.
Link: https://lore.kernel.org/linux-trace-devel/20220514024756.1319681-23-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add tracecmd_msg_flush_data() that will flush the current cached data to
the network and restart the cache file.
Link: https://lore.kernel.org/linux-trace-devel/20220514024756.1319681-22-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a new interface tracecmd_prepare_options() that can be used by
tracecmd_msg to update the next options before flushing over the network.
Once the last options is written to the network, it can not be updated to
point to the next options section.
The tracecmd_prepare_options() will update the last options in the file to
point to the offset of the next one (before they are written). The
location of the next options must be known (obviously), but this means
that the data can be flushed over the network before the next options are
written. The use case is where there's options that need to be added when
the trace is done, but the beginning of the trace file is already sent out
over the network.
Link: https://lore.kernel.org/linux-trace-devel/20220514024756.1319681-21-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
The proxy agent will need to send data in two chunks, and will need to
save the offset of the flushed cache so that it can be used later.
Link: https://lore.kernel.org/linux-trace-devel/20220514024756.1319681-20-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add:
trace-cmd agent -P <cid>
to allow an agent to also act as a proxy server, where it can be run on a
host and connect with a guest. The <cid> is the guest's cid that it will
connect to (it will only connect to a specified guest).
Add:
trace-cmd record --proxy ...
That acts the same as -A (for an agent) but will send the proxy connection
to the agent. It is expected to run on a privilege guest that the host is
aware of (as denoted by the <cid> in the -P option for the agent).
Link: https://lore.kernel.org/linux-trace-devel/20220514024756.1319681-19-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add communication for an agent proxy. When an agent is also running as a
proxy, it will be able to receive a TRACE_PROXY message. This will contain
the same data as a TRACE_REQ, but also include the number of CPUs the
recorder has (as the recorder may be running on the guest, and the agent
on the host), as well as the number of siblings guests that will be sent
afterward.
The sibling messages will come at a later time.
Currently there are no users of this API.
Link: https://lore.kernel.org/linux-trace-devel/20220514024756.1319681-18-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Create a trace-tsync.c file to house the tsync host and guest helper
functions, and have the trace-record.c and trace-agent.c call them.
This is just a clean up to simplify the code for when an agent proxy is
added.
Also add some comments about these functions.
Link: https://lore.kernel.org/linux-trace-devel/20220514024756.1319681-17-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
In the process of adding an agent proxy, it will be useful to have a
function that will allow the agent to synchronize as the host. Move the
code to do so into a helper function that can be used by the agent. This
will be later moved to a separate file.
Link: https://lore.kernel.org/linux-trace-devel/20220514024756.1319681-16-rostedt@goodmis.org
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
