From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: "Frédéric Weisbecker" <fweisbec@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
Jens Axboe <jens.axboe@oracle.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: trace_seq_printf/.print_line question
Date: Tue, 16 Dec 2008 12:10:03 -0200 [thread overview]
Message-ID: <20081216141003.GK14518@ghostprotocols.net> (raw)
Jens, just a FYI about this stuff, not yet ready for reviewing.
Hi Frédéric, Steven,
Have you guys ever get into this kind of situation?
[root@mica linux-2.6-tip]# cat /sys/kernel/debug/tracing/trace | tail
kjournald-480 [000] 593.219805: C W 2149459 + 8 [0]
<idle>-0 [000] 593.219849: A WS 2149467 + 8 <- (8,2) 44952
kjournald-480 [000] 607.210959: Q WS 2149467 + 8
kjournald-480 [000] 607.210960: G WS 2149467 + 8
kjournald-480 [000] 607.210963: P N
kjournald-480 [000] 607.210964: I W 2149467 + 8
kjournald-480 [000] 607.210965: D W 2149467 + 8
kjournald-480 [000] 607.210967: U N 1
kjournald-480 [000] 607.210971: C W 2149467 + 8 [0]
<idle>-0 [000] 607.211049: [root@mica linux-2.6-tip]#
[root@mica linux-2.6-tip]# head /sys/kernel/debug/tracing/trace
# tracer: blk
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
A W 2147707 + 8 <- (8,2) 43192
kjournald-480 [000] 254.428659: Q W 2147707 + 8
kjournald-480 [000] 254.428661: G W 2147707 + 8
kjournald-480 [000] 254.428663: I W 100410211 + 8
pdflush-261 [000] 147.328259: P N
kjournald-480 [000] 254.428664: I W 2147707 + 8
[root@mica linux-2.6-tip]#
This is happening in an experiment I'm doing in porting blktrace to the
tracing/ring_buffer infrastructure, the problem always happens at this
function:
static int blk_log_remap(struct trace_seq *s, struct blk_io_entry *t)
{
char rwbs[6];
struct blk_io_trace_remap r = { .device = 0, };
get_pdu_remap(t, &r);
t->device = r.device_from;
fill_rwbs(rwbs, t);
return trace_seq_printf(s, " A %3s %llu + %u <- (%d,%d) %llu\n",
rwbs, (unsigned long long)t->sector,
t_sec(t), MAJOR(r.device), MINOR(r.device),
(unsigned long long)r.sector);
}
And the registered .print_line routine does check the return of
trace_seq_printf:
if (!ret)
return TRACE_TYPE_PARTIAL_LINE;
}
default:
return TRACE_TYPE_UNHANDLED;
}
return TRACE_TYPE_HANDLED;
}
Full patch, still WIPish:
http://oops.ghostprotocols.net:81/acme/blkftrace.patch
- Arnaldo
next reply other threads:[~2008-12-16 14:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-16 14:10 Arnaldo Carvalho de Melo [this message]
2008-12-16 16:18 ` trace_seq_printf/.print_line question Frédéric Weisbecker
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=20081216141003.GK14518@ghostprotocols.net \
--to=acme@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.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.