All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	lttng-dev <lttng-dev@lists.lttng.org>,
	KVM list <kvm@vger.kernel.org>,
	Sean Christopherson <seanjc@google.com>
Subject: Re: [lttng-dev] Unexport of kvm_x86_ops vs tracer modules
Date: Mon, 25 Apr 2022 12:02:52 -0400 (EDT)	[thread overview]
Message-ID: <892959086.34940.1650902572304.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20220425100434.2f5d18bb@gandalf.local.home>

----- On Apr 25, 2022, at 10:04 AM, Steven Rostedt rostedt@goodmis.org wrote:

> On Fri, 8 Apr 2022 14:06:53 -0400 (EDT)
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
>> 
>> Indeed, the fact that the TP_fast_assign snippets are embedded in the
>> trace_event_raw_event_* symbols is an issue for LTTng. This ties those
>> to ftrace.
> 
> Not just ftrace, perf does it too.
> 
> Now another solution is to make the fast assigns available to anyone, and
> to allow you to simply pass in a pointer and size to have the data written
> into it. That is, you get the results of the TRACE_EVENT and not have to
> depend on internal data from the tracepoint.

If the fast assign can then be used on a field-per-field basis, maybe this
could work, but AFAIK the fast-assign macro is open-coded C, which makes this
not straightforward.

If it's a all-or-nothing approach where the fast-assign needs to serialize all
fields, this would require that lttng copies the data into a temporary area,
which is something I want to avoid for filtering and event notification per-field
payload capture purposes.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	KVM list <kvm@vger.kernel.org>,
	lttng-dev <lttng-dev@lists.lttng.org>,
	Michael Jeanson <mjeanson@efficios.com>
Subject: Re: Unexport of kvm_x86_ops vs tracer modules
Date: Mon, 25 Apr 2022 12:02:52 -0400 (EDT)	[thread overview]
Message-ID: <892959086.34940.1650902572304.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20220425100434.2f5d18bb@gandalf.local.home>

----- On Apr 25, 2022, at 10:04 AM, Steven Rostedt rostedt@goodmis.org wrote:

> On Fri, 8 Apr 2022 14:06:53 -0400 (EDT)
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
>> 
>> Indeed, the fact that the TP_fast_assign snippets are embedded in the
>> trace_event_raw_event_* symbols is an issue for LTTng. This ties those
>> to ftrace.
> 
> Not just ftrace, perf does it too.
> 
> Now another solution is to make the fast assigns available to anyone, and
> to allow you to simply pass in a pointer and size to have the data written
> into it. That is, you get the results of the TRACE_EVENT and not have to
> depend on internal data from the tracepoint.

If the fast assign can then be used on a field-per-field basis, maybe this
could work, but AFAIK the fast-assign macro is open-coded C, which makes this
not straightforward.

If it's a all-or-nothing approach where the fast-assign needs to serialize all
fields, this would require that lttng copies the data into a temporary area,
which is something I want to avoid for filtering and event notification per-field
payload capture purposes.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2022-04-25 16:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-08 15:36 [lttng-dev] Unexport of kvm_x86_ops vs tracer modules Mathieu Desnoyers via lttng-dev
2022-04-08 15:36 ` Mathieu Desnoyers
2022-04-08 16:24 ` [lttng-dev] " Paolo Bonzini via lttng-dev
2022-04-08 16:24   ` Paolo Bonzini
2022-04-08 18:06   ` [lttng-dev] " Mathieu Desnoyers via lttng-dev
2022-04-08 18:06     ` Mathieu Desnoyers
2022-04-25 13:00     ` [lttng-dev] " Mathieu Desnoyers via lttng-dev
2022-04-25 13:00       ` Mathieu Desnoyers
2022-04-25 13:28       ` Paolo Bonzini via lttng-dev
2022-04-25 13:28         ` Paolo Bonzini
2022-04-25 14:04     ` Steven Rostedt via lttng-dev
2022-04-25 14:04       ` Steven Rostedt
2022-04-25 16:02       ` Mathieu Desnoyers via lttng-dev [this message]
2022-04-25 16:02         ` Mathieu Desnoyers
2022-04-25 19:13         ` [lttng-dev] " Steven Rostedt via lttng-dev
2022-04-25 19:13           ` Steven Rostedt
2022-04-26  6:36         ` [lttng-dev] " Paolo Bonzini via lttng-dev
2022-04-26  6:36           ` Paolo Bonzini

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=892959086.34940.1650902572304.JavaMail.zimbra@efficios.com \
    --to=lttng-dev@lists.lttng.org \
    --cc=kvm@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=pbonzini@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=seanjc@google.com \
    /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.