From: Paolo Bonzini <pbonzini@redhat.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: Kevin Wolf <kwolf@redhat.com>,
Anthony Liguori <aliguori@us.ibm.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel@nongnu.org, liu ping fan <qemulist@gmail.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>,
rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCHv1 0/4] Timers: add timer debugging through -timer-debug-log
Date: Sat, 26 Oct 2013 08:18:23 +0100 [thread overview]
Message-ID: <526B6CBF.9050408@redhat.com> (raw)
In-Reply-To: <B2882D01-5E49-47D0-A4B8-617D9718D16E@alex.org.uk>
Il 26/10/2013 06:52, Alex Bligh ha scritto:
>
> On 26 Oct 2013, at 00:00, Paolo Bonzini wrote:
>
>> his is a bug in the distro, if it is Linux. There is no reason not to
>> enable the stap trace format when running on Linux (Fedora does for
>> other packages than QEMU, too---most notably glib and glibc).
>>
>> If it is useful, adding debugging information to timer_new_ns (please
>> make file and line two separate arguments, though) can definitely be
>> done unconditionally and added to the traces. I think adding a
>> tracepoint in timerlist_run_timers would provide very similar
>> information to that in your file.
>
> I read the tracepoint information. Doesn't that require the end
> user to have far more skills (and far more stuff installed) to
> get things like "average expiry delta"? Especially as that's
> not something we'd normally calculate as we don't get the clock
> value when setting a timer normally.
The simple trace backend includes a nanosecond value that is the same as
rt_clock, so you can correlate the last timer_mod with the next
iteration in timerlist_run_timers (I would put the tracepoint inside the
loop, just before the callback is done). Similarly, in systemtap you
can just use the builtin gettimeofday_ns() function
All clocks are basically in nanoseconds (the only difference between
vm_clock and rt_clock is that the former stops when the VM is stopped),
so you can get the average expiry delta from there.
Of course it requires some postprocessing or a systemtap script, but we
can put that into scripts/ or give it to the user. See
https://sourceware.org/ml/systemtap/2011-q3/txt00003.txt for an example,
I suppose the "expiry time" computation would look like this:
global modtime, expirytot, firedcnt
probe qemu.system.x86_64.timer_mod {
loc = sprintf("%s:%d", timer_file, timer_line)
modtime[pid(), loc] = gettimeofday_ns()
}
probe qemu.system.x86_64.timer_run {
loc = sprintf("%s:%d", timer_file, timer_line)
expirytot[pid(), loc] += gettimeofday_ns() - modtime[pid(), loc]
firedcnt[pid(), loc]++
}
probe end
{
printf("\n%8s %28s %8s %8s\n", "pid", "loc", "avg expiry", "cnt")
foreach([p+, loc] in firedcnt) {
printf("%8d %28s %8d %8d\n", p, loc,
expirytot[p, loc] / firedcnt[p, loc],
firedcnt[p, loc])
}
}
which I wrote based on the example at
http://cygwin.com/ml/systemtap/2011-q3/msg00316.html
I understand your usecase, but it's not really feasible to add a logging
option for each tracing need; it's much better to add new tracepoints
and distribute sample systemtap scripts. And please "lobby" your distro
for enabling systemtap support and distributing the .stp file!
Paolo
next prev parent reply other threads:[~2013-10-26 7:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-25 22:30 [Qemu-devel] [PATCHv1 0/4] Timers: add timer debugging through -timer-debug-log Alex Bligh
2013-10-25 22:30 ` [Qemu-devel] [PATCHv1 1/4] Timers: add debugging macros wrapping timer functions and debug structures Alex Bligh
2013-10-25 22:30 ` [Qemu-devel] [PATCHv1 2/4] Timers: add command line option -timer-debug-log Alex Bligh
2013-10-25 22:30 ` [Qemu-devel] [PATCHv1 3/4] Timers: Instrument timer_mod Alex Bligh
2013-10-25 22:30 ` [Qemu-devel] [PATCHv1 4/4] Timers: produce timer-debug-log file Alex Bligh
2013-10-25 23:00 ` [Qemu-devel] [PATCHv1 0/4] Timers: add timer debugging through -timer-debug-log Paolo Bonzini
2013-10-26 5:52 ` Alex Bligh
2013-10-26 7:18 ` Paolo Bonzini [this message]
2013-10-26 8:24 ` Alex Bligh
2013-10-26 17:11 ` 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=526B6CBF.9050408@redhat.com \
--to=pbonzini@redhat.com \
--cc=alex@alex.org.uk \
--cc=aliguori@us.ibm.com \
--cc=jan.kiszka@siemens.com \
--cc=kwolf@redhat.com \
--cc=morita.kazutaka@lab.ntt.co.jp \
--cc=qemu-devel@nongnu.org \
--cc=qemulist@gmail.com \
--cc=rth@twiddle.net \
--cc=stefanha@redhat.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;
as well as URLs for NNTP newsgroup(s).