# libtracefs(3) Manual Page

## NAME

tracefs_sql - Create a synthetic event via an SQL statement

## SYNOPSIS

    #include <tracefs.h>

    struct tracefs_synth *tracefs_sql(struct tep_handle *tep, const char *name,
                                            const char *sql_buffer, char **err);

## DESCRIPTION

Synthetic events are dynamically created events that attach two existing events together via one or more matching fields between the two events. It can be used to find the latency between the events, or to simply pass fields of the first event on to the second event to display as one event.

The Linux kernel interface to create synthetic events is complex, and there needs to be a better way to create synthetic events that is easy and can be understood via existing technology.

If you think of each event as a table, where the fields are the column of the table and each instance of the event as a row, you can understand how SQL can be used to attach two events together and form another event (table). Utilizing the SQL SELECT FROM JOIN ON [ WHERE ] syntax, a synthetic event can easily be created from two different events.

For simple SQL queries to make a histogram instead of a synthetic event, see HISTOGRAMS below.

tracefs_sql() takes in a tep handler (See tep_local_events(3)) that is used to verify the events within the sql_buffer expression. The name is the name of the synthetic event to create. If err points to an address of a string, it will be filled with a detailed message on any type of parsing error, including fields that do not belong to an event, or if the events or fields are not properly compared.

The example program below is a fully functional parser where it will create a synthetic event from a SQL syntax passed in via the command line or a file.

The SQL format is as follows:

SELECT <fields> FROM <start-event> JOIN <end-event> ON <matching-fields> WHERE <filter>

Note, although the examples show the SQL commands in uppercase, they are not required to be so. That is, you can use "SELECT" or "select" or "sElEct".

For example:

Will create a synthetic event that with the fields:

    u64 fd; s64 ret;

Because the function takes a tep handle, and usually all event names are unique, you can leave off the system (group) name of the event, and tracefs_sql() will discover the system for you.

That is, the above statement would work with:

The AS keyword can be used to name the fields as well as to give an alias to the events, such that the above can be simplified even more as:

The above aliases sys_enter_read as start and sys_exit_read as end and uses those aliases to reference the event throughout the statement.

Using the AS keyword in the selection portion of the SQL statement will define what those fields will be called in the synthetic event.

The above labels the fd of start as filed and the ret of end as return where the synthetic event that is created will now have the fields:

    u64 filed; s64 return;

The fields can also be calculated with results passed to the synthetic event:

Which would show the truesize of the napi_gro_receive_entry event, the actual len of the content, shown by the netif_receive_skb, and the delta between the two and expressed by the field diff.

The code also supports recording the timestamps at either event, and performing calculations on them. For wakeup latency, you have:

The above will create a synthetic event that records the pid of the task being woken up, and the time difference between the sched_waking event and the sched_switch event. The TIMESTAMP_USECS will truncate the time down to microseconds as the timestamp usually recorded in the tracing buffer has nanosecond resolution. If you do not want that truncation, use TIMESTAMP instead of TIMESTAMP_USECS.

Because it is so common to have:

The above can be represented with TIMESTAMP_DELTA_USECS or if nanoseconds are OK, you can use TIMESTAMP_DELTA. That is, the previous select can also be represented by:

Finally, the WHERE clause can be added, that will let you add filters on either or both events.

NOTE

Although both events can be used together in the WHERE clause, they must not be mixed outside the top most "&&" statements. You can not OR (||) the events together, where a filter of one event is OR’d to a filter of the other event. This does not make sense, as the synthetic event requires both events to take place to be recorded. If one is filtered out, then the synthetic event does not execute.

The above is valid.

Where as the below is not.

If the kernel supports it, you can pass around a stacktrace between events.

The above will record a stacktrace when a task is in the UNINTERRUPTIBLE (blocked) state, and trigger the synthetic event when it is scheduled back in, recording the time delta that it was blocked for. It will record the stacktrace of where it was when it scheduled out along with the delta.

## KEYWORDS AS EVENT FIELDS

In some cases, an event may have a keyword. For example, regcache_drop_region has "from" as a field and the following will not work

In such cases, add a backslash to the conflicting field, and this will tell the parser that the "from" is a field and not a keyword:

## HISTOGRAMS

Simple SQL statements without the JOIN ON may also be used, which will create a histogram instead. When doing this, the struct tracefs_hist descriptor can be retrieved from the returned synthetic event descriptor via the tracefs_synth_get_start_hist(3).

In order to utilize the histogram types (see xxx) the CAST command of SQL can be used.

That is:

Which produces:

Note, string fields may not be cast.

The possible types to cast to are:

HEX - convert the value to use hex and not decimal

SYM - convert a pointer to symbolic (kallsyms values)

SYM-OFFSET - convert a pointer to symbolic and include the offset.

SYSCALL - convert the number to the mapped system call name

EXECNAME or COMM - can only be used with the common_pid field. Will show the task name of the process.

LOG or LOG2 - bucket the key values in a log 2 values (1, 2, 3-4, 5-8, 9-16, 17-32, …)

The above fields are not case sensitive, and "LOG2" works as good as "log".

A special CAST to COUNTER or COUNTER will make the field a value and not a key. For example:

Which will create

## RETURN VALUE

Returns 0 on success and -1 on failure. On failure, if err is defined, it will be allocated to hold a detailed description of what went wrong if it the error was caused by a parsing error, or that an event, field does not exist or is not compatible with what it was combined with.

## CREATE A TOOL

The below example is a functional program that can be used to parse SQL commands into synthetic events.

Then you can run the above examples:

## EXAMPLE

## FILES

    tracefs.h
            Header file to include in order to have access to the library APIs.
    -ltracefs
            Linker switch to add when building a program that uses the library.

## SEE ALSO

sqlhist(1), libtracefs(3), libtraceevent(3), trace-cmd(1), tracefs_synth_init(3), tracefs_synth_add_match_field(3), tracefs_synth_add_compare_field(3), tracefs_synth_add_start_field(3), tracefs_synth_add_end_field(3), tracefs_synth_append_start_filter(3), tracefs_synth_append_end_filter(3), tracefs_synth_create(3), tracefs_synth_destroy(3), tracefs_synth_free(3), tracefs_synth_echo_cmd(3), tracefs_hist_alloc(3), tracefs_hist_alloc_2d(3), tracefs_hist_alloc_nd(3), tracefs_hist_free(3), tracefs_hist_add_key(3), tracefs_hist_add_value(3), tracefs_hist_add_name(3), tracefs_hist_start(3), tracefs_hist_destory(3), tracefs_hist_add_sort_key(3), tracefs_hist_sort_key_direction(3)

## AUTHOR

    Steven Rostedt <rostedt@goodmis.org>
    Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
    sameeruddin shaik <sameeruddin.shaik8@gmail.com>

## REPORTING BUGS

Report bugs to <linux-trace-devel@vger.kernel.org>

## LICENSE

libtracefs is Free Software licensed under the GNU LGPL 2.1

## RESOURCES

https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/

## COPYING

Copyright (C) 2020 VMware, Inc. Free use of this software is granted under the terms of the GNU Public License (GPL).