Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
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.




  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