All of lore.kernel.org
 help / color / mirror / Atom feed
From: Beau Belgrave <beaub@linux.microsoft.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: linux-trace-devel@VGER.KERNEL.ORG, rostedt@goodmis.org,
	zanussi@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] synth_events: Do not block other dyn_event systems during create
Date: Fri, 1 Oct 2021 08:57:46 -0700	[thread overview]
Message-ID: <20211001155746.GA16348@kbox> (raw)
In-Reply-To: <20211001125513.cf40fa1a3188416582666f66@kernel.org>

> Thanks for clean up the synthetic event!
> This looks good to me.
> 
> Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
No problem, thanks for the review!

> So now are you trying to reuse synth event for user event?
> Then I think you need to register a new dyn_event ops so
> that histogram will not submit the event.
A user events patch will get sent out soon, I'm finalizing some testing.
User events will register it's own dyn_event ops and allow users the
option to create, delete and view status of user events via the
dynamic_events tracefs file (in addition to the user mode IOCTL/ABI).

As probes attach to the user events the status of this is reflected in
dynamic_events, which makes it easy for admins to see why one is busy,
etc. It also makes it easy to verifying the system is working as
expected with just a terminal.

> BTW, how do you filter an event written by a user process?
> Will you add an array of event id for the file data structure?
The filtering would happen at the trace_event level, the only filtering
at the user event level is if a probe has been enabled on the underlying
trace_event or not. That is done via the shared page bits being cleared
or set. Bits are updated as probe un/registrations occur.

Users can advertise field values, offsets, etc as well as the print_fmt
in the newer ABI/patch based on the feedback from LPC2021. These land in
the trace_event fields and are viewable via tracefs like any other
evnet. I hope that is enough to light up the history feature of trace_event.
I am not familiar with it as much as you all.

Thanks,
-Beau

      reply	other threads:[~2021-10-01 15:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30 22:38 [PATCH] synth_events: Do not block other dyn_event systems during create Beau Belgrave
2021-10-01  3:55 ` Masami Hiramatsu
2021-10-01 15:57   ` Beau Belgrave [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=20211001155746.GA16348@kbox \
    --to=beaub@linux.microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-devel@VGER.KERNEL.ORG \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.