linux-trace-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Anthony Eden <aeden@csail.mit.edu>
Cc: linux-trace-users@vger.kernel.org, Slavomir Kaslev <kaslevs@vmware.com>
Subject: Re: increase size of number of possible tracing events
Date: Wed, 26 Jun 2019 11:46:01 -0400	[thread overview]
Message-ID: <20190626114601.6510c943@gandalf.local.home> (raw)
In-Reply-To: <CAHMsQjVYHY1N=X9emeYg34XxeUaMRdV--3NYFNdy111sD0-0gg@mail.gmail.com>

On Fri, 21 Jun 2019 18:14:54 -0400
Anthony Eden <aeden@csail.mit.edu> wrote:

> I am trying to develop a patch which increases the maximum number of
> possible tracing events (i.e. TRACE_EVENT_TYPE_MAX). I naively tried
> changing unsigned short trace_entry::type to unsigned int (that simply
> broke tracing).
> 
> Short background: I am placing a UProbe tracepoint at the start of
> every basic block for every DSO in a dynamically-linked program. I
> recently hit the ceiling for the maximum number of tracepoints with
> dnsmasq;
> 
> /usr/bin/dnsmasq:            12826 basic blocks
> /usr/lib/libc.so.6:          60511 basic blocks
> /lib64/ld-linux-x86-64.so.2: 6270 basic blocks
> linux-vdso.so.1:             36 basic blocks
> 
> Writing to /sys/kernel/debug/tracing/uprobe_events returns -ENODEV. If
> anyone could provide some guidance towards raising the limit, it would
> be much appreciated.
>

I'm not sure having over 65535 different events is a good idea. Perhaps
we should create a different type of uprobe that can be reused, as I'm
sure you are not making each of these events record different data.
Basically make it similar to the function tracing event, which is a
single event that records the function that it traces, and not
thousands of different individual events.

Would something like that be helpful for you? It still requires a
kernel change, but that is still possible.

-- Steve

  parent reply	other threads:[~2019-06-26 15:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-21 22:14 increase size of number of possible tracing events Anthony Eden
2019-06-21 23:13 ` Steven Rostedt
2019-06-26 15:46 ` Steven Rostedt [this message]
2019-06-27 16:44   ` Anthony Eden
2019-06-30 14:31     ` Anthony Eden
2019-07-01 12:58       ` Frank Ch. Eigler

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=20190626114601.6510c943@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=aeden@csail.mit.edu \
    --cc=kaslevs@vmware.com \
    --cc=linux-trace-users@vger.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).