From: Paul_Woegerer@mentor.com (Woegerer, Paul)
Subject: [lttng-dev] lttng enable-channel option for blocking
Date: Fri, 27 Apr 2012 09:28:17 +0200 [thread overview]
Message-ID: <4F9A4A91.7090102@mentor.com> (raw)
In-Reply-To: <20120426211627.GB1646@Krystal>
On 04/26/2012 11:16 PM, Mathieu Desnoyers wrote:
> I already thought about permitting this, but we currently don't. The
> first thing I must say about this is that I prefer to wait a bit
> before we add this feature, and think about its impact thoroughly,
> because allowing the tracer to block applications gives a lot of power
> to the tracer: e.g., if tracing is stopped due to error conditions, or
> disk full, or network traffic slowdown, how do we handle the fact that
> this might block progress in all traced applications ?
Good to know that this is on the agenda.
I agree, it gives a lot of power to the tracer. By messing with channel
configurations a user could make a tracing application unusable. But the
user already has ways to make applications unusable (by messing with
ulimit, for example). There is always enough rope to hang yourself.
> The current modes (discard and overwrite) let the applications continue
> even if there is too much data being recorded into the trace buffers --
> this is a "safe" approach.
>
> How would you recommend dealing with the possible pitfalls of blocking
> traced applications ? We would need a mechanism in place to ensure
> gathering a trace cannot make applications unresponsive.
I guess in case of "lttng enable-channel --block" a user would have to
expect that a call to tracepoint() might block. He has to deal with the
fact in his application domain (e.g. implement a watchdog mechanism).
Nonetheless it might be a good idea to also provide something like
tracepointnb() ( a non-blocking variant of tracepoint() ) in case the
user doesn't want to deal with (or simply cannot accept) potential blocking.
--
Thanks,
Paul
--
Paul Woegerer | SW Development Engineer
Mentor Embedded(tm) | Prinz Eugen Stra?e 72/2/4, Vienna, 1040 Austria
P 43.1.535991320
Nucleus? | Linux? | Android(tm) | Services | UI | Multi-OS
Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
next prev parent reply other threads:[~2012-04-27 7:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-26 10:23 Woegerer, Paul
2012-04-26 21:16 ` Mathieu Desnoyers
2012-04-27 7:28 ` Woegerer, Paul [this message]
2012-04-27 11:33 ` Mathieu Desnoyers
2012-04-27 11:50 ` Woegerer, Paul
2012-04-27 12:43 ` Mathieu Desnoyers
2012-04-27 16:15 ` Woegerer, Paul
2012-04-30 14:20 ` Mathieu Desnoyers
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=4F9A4A91.7090102@mentor.com \
--to=paul_woegerer@mentor.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox