Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Subject: [ltt-dev] lost events due to non consumed full buffers
Date: Fri, 30 Jan 2009 09:52:12 -0500	[thread overview]
Message-ID: <20090130145212.GA10686@Krystal> (raw)
In-Reply-To: <1E65288790442545B413D69F2A8D27DE046A36E2@ERLD164A.ww004.siemens.net>

* Akyurek, Ali (EXT) (ali.akyurek.ext at siemens.com) wrote:
> 
> Hi all,
> 
> Below is a code snippet from ltt-relay.c of LTTng 0.9.10 running on the 2.6.22 kernel.
> I got approx. 70000 lost events during tracing.
> I've seen that the problem is non consumed full buffers, as i show with an arrow below.

The problem is more exactly :

your consumer (lttd) is not fast enough to get the data from the writer
(the kernel).

Check that lttd is executing while you take your trace in hybrid and
normal tracing modes.

Other solutions are to use the "flight recorder" mode, the "hybrid"
mode, or to make your buffers larger. You might also want to export your
data through a NFS mount rather than writing it to disk if the disk is
the bottleneck.

Mathieu


> This problem occurs when my user space application initializes itself.
> 
> What do you think about the problem of not consuming? What may cause this?
> 
> Thanks.
> 
> -----------------------------------------------------------------------
> 			reserve_commit_diff = SUBBUF_OFFSET(
> 				buf->chan->subbuf_size - local_read(
> 				&ltt_buf->commit_count[
> 						SUBBUF_INDEX(offset_begin,
> 						buf->chan)]), buf->chan);
> 			if (reserve_commit_diff == 0) {
> 				/* Next buffer not corrupted. */
> 				if (!ltt_channel->overwrite &&
> 					(SUBBUF_TRUNC(offset_begin, buf->chan)
> 					- SUBBUF_TRUNC(
> 					atomic_long_read(&ltt_buf->consumed),
> 					buf->chan))
> 					>= rchan->alloc_size) {
> 					/*
> 					 * We do not overwrite non consumed
> 					 * buffers and we are full : event
> 					 * is lost.
> 					 */
> 					/* printk("non_con_buf\n"); */
> 		==========>		local_inc(&ltt_buf->events_lost);
> 					return NULL;
> 				} else {
> 					/*
> 					 * next buffer not corrupted, we are
> 					 * either in overwrite mode or the
> 					 * buffer is not full. It's safe to
> 					 * write in this new subbuffer.
> 					 */
> 				}
> 			}
> ---------------------------------------------------------------------
>  
> Mit freundlichem Gruss / Best Regards
> Ali G?nhan Aky?rek 
> evosoft
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68




      reply	other threads:[~2009-01-30 14:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-30 14:27 Akyurek, Ali (EXT)
2009-01-30 14:52 ` Mathieu Desnoyers [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=20090130145212.GA10686@Krystal \
    --to=compudj@krystal.dyndns.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