linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: linux-trace-devel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Tom Zanussi <zanussi@kernel.org>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	linux-rt-users <linux-rt-users@vger.kernel.org>,
	Clark Williams <williams@redhat.com>
Subject: Re: [PATCH 00/17] libtracefs: Introducing tracefs_sql() to create synthetice events with an SQL line
Date: Fri, 30 Jul 2021 18:31:36 -0400	[thread overview]
Message-ID: <20210730183136.46eeb036@oasis.local.home> (raw)
In-Reply-To: <20210730221824.595597-1-rostedt@goodmis.org>

On Fri, 30 Jul 2021 18:18:07 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> FUNCTIONAL EXAMPLE:
> -------------------
> 
> After applying this patch, and installing it. If you compile the example from the man
> page (calling it sqlhist.c):
> 
>  >$ gcc -o sqlhist sqlhist.c `pkg-config --cflags --libs libtracefs`
>  >$ su
>  ># ./sqlhist -n syscall_wait -e 'select start.id, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) as lat  
>     from sys_enter as start join sys_exit as end on start.common_pid = end.common_pid
>     where start.id != 23 && start.id != 7 && start.id != 61 && start.id != 230 &&
>           start.id != 232 && start.id != 270 && start.id != 271 && start.id != 202'
> 
> 
> (All the start.id filtering is hiding the syscalls that block for a long time)
> 
>  ># echo 'hist:keys=id.syscall,lat.buckets=10:sort=lat' > /sys/kernel/tracing/events/synthetic/syscall_wait/trigger  
> 
> <wait a while>
> 
>  ># cat /sys/kernel/tracing/events/synthetic/syscall_wait/hist  

And of course, I forgot to say what the above is doing :-p

I wanted to see how long syscalls block for. So I created a synthetic
event that connects with the starting of all system calls, with the
exit of the same system call, using the common_pid of the task as the
key to connect the two.

I record the id of the system call as well as the latency that is
recorded, and send that off to a synthetic event called "syscall_wait".

The '-e' option of the man page program sqlhist executes the command to
create the synthetic event.

Then I add a histogram to that event keying off the id (the ".syscall"
writes out the name of the system call along with the id), and the
latency "lat" grouping it in buckets of "5 microseconds", and sort it
by the latency.

I waited a while, and then reported the result.

When I first ran this, the system calls that block for a long time
filled up the histogram with useless data.  Those were the various
"poll" and "select" as well as (surprising) "futex" system call.

-- Steve

      parent reply	other threads:[~2021-07-30 22:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-30 22:18 [PATCH 00/17] libtracefs: Introducing tracefs_sql() to create synthetice events with an SQL line Steven Rostedt
2021-07-30 22:18 ` [PATCH 01/17] libtracefs: Added new API tracefs_sql() Steven Rostedt
2021-08-01  6:32   ` Ahmed S. Darwish
2021-08-01 22:10     ` Steven Rostedt
2021-08-02 23:45   ` Namhyung Kim
2021-08-03  2:49     ` Steven Rostedt
2021-07-30 22:18 ` [PATCH 02/17] tracefs: Add unit tests for tracefs_sql() Steven Rostedt
2021-07-30 22:18 ` [PATCH 03/17] libtracefs: Add comparing start and end fields in tracefs_sql() Steven Rostedt
2021-07-30 22:18 ` [PATCH 04/17] libtracefs: Add unit test to test tracefs_sql() compare Steven Rostedt
2021-07-30 22:18 ` [PATCH 05/17] libtracefs: Add filtering for start and end events in tracefs_sql() Steven Rostedt
2021-07-30 22:18 ` [PATCH 06/17] libtracefs: Add unit test to test tracefs_sql() where clause Steven Rostedt
2021-07-30 22:18 ` [PATCH 07/17] libtracefs: Make sqlhist parser reentrant Steven Rostedt
2021-07-30 22:18 ` [PATCH 08/17] libtracefs: Make parser unique to libtracefs Steven Rostedt
2021-07-30 22:18 ` [PATCH 09/17] libtracefs: Add line number and index to expr structure Steven Rostedt
2021-07-30 22:18 ` [PATCH 10/17] libtracefs: Add a parse_error() helper function to record errors Steven Rostedt
2021-07-30 22:18 ` [PATCH 11/17] libtracefs: Add error message when match fields are not FROM and JOIN events Steven Rostedt
2021-07-30 22:18 ` [PATCH 12/17] libtracefs: Add error message when match or init fails from bad events Steven Rostedt
2021-07-30 22:18 ` [PATCH 13/17] libtracefs; Add error message for bad selections to SQL sequence Steven Rostedt
2021-07-30 22:18 ` [PATCH 14/17] libtracefs: Add error message when compare fields fail Steven Rostedt
2021-07-30 22:18 ` [PATCH 15/17] libtracefs: Add error message for grouping events in SQL filter Steven Rostedt
2021-07-30 22:18 ` [PATCH 16/17] libtracefs: Add error message for bad filters in SQL statement Steven Rostedt
2021-07-30 22:18 ` [PATCH 17/17] libtracefs: Add man page for tracefs_sql() Steven Rostedt
2021-08-01 13:39   ` Ahmed S. Darwish
2021-08-01 22:29     ` Steven Rostedt
2021-08-04 12:27       ` Ahmed S. Darwish
2021-07-30 22:31 ` Steven Rostedt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210730183136.46eeb036@oasis.local.home \
    --to=rostedt@goodmis.org \
    --cc=bristot@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=williams@redhat.com \
    --cc=zanussi@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).