qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).