qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] timer issue on 1.7.0 and later


From: Alex Bligh
Subject: Re: [Qemu-devel] timer issue on 1.7.0 and later
Date: Sat, 8 Feb 2014 15:20:01 +0000

Paolo,

On 8 Feb 2014, at 13:26, Paolo Bonzini wrote:

>> 
>> What I'd suggest you do is run qemu within gdb, and when you have
>> seen the sluggish behaviour, set a breakpoint in timerlist_run_timers
>> just before the line saying cb(opaque). If I'm right your breakpoint
>> should immediately hit. Step in to the callback and note which it is.
>> It should always (or nearly always) be the same timer (note the process
>> of debugging will cause other timers to expire).
> 
> Alex, could you add a trace event to timerlist_run_timers and mod_timer?  For 
> timerlist_run_timer it should include the timer (ts), the callback and the 
> opaque value.
> 
> This would make it simpler to find if this is the cause, and to debug it 
> without introducing as much perturbation.

A while ago a wrote some instrumentation. I can't recall how far I got with
testing it, but here it is rebased onto master without so much as a compile test
(top 4 commits - ignore the 5th):
   
https://github.com/abligh/qemu/commit/e711816da9831c97f7d8a111b610ef42f7ba69fa

As is evident, this does not use the qemu trace infrastructure (and it needs
to be rewritten to do that). However, it does usefully instrument the timers
in that it records where they are registered (by file & line number),
counts expiries, short timer expiries (currently less than 1 microsecond),
measures average expiry length etc. What I was trying to do was to get a single
file out that would very obviously determine whether timers were the cause
of slowness, and if so which timer was guilty.

I agree re the tracepoints. How much of the rest of this is useful? Is there
currently a debug mechanism in qemu where you can say "dump some stats out"
that doesn't require adding command line options and the like?

-- 
Alex Bligh







reply via email to

[Prev in Thread] Current Thread [Next in Thread]