qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/3] monitor: show sync profiling info with 'inf


From: Peter Xu
Subject: Re: [Qemu-devel] [PATCH 2/3] monitor: show sync profiling info with 'info sync'
Date: Thu, 16 Aug 2018 21:20:02 +0800
User-agent: Mutt/1.10.0 (2018-05-17)

On Tue, Aug 14, 2018 at 09:26:09PM -0400, Emilio G. Cota wrote:
> On Tue, Aug 14, 2018 at 10:14:01 +0200, Paolo Bonzini wrote:
> > On 13/08/2018 19:11, Emilio G. Cota wrote:
> > Would it make sense to add a flag to sort by average wait time
> 
> Done:
> 
> (qemu) help info sync-profile
> info sync-profile [-m] [max] -- show sync profiling info \
> for up to max entries (default: 10). By default, entries \
> are sorted by total wait time; -m sorts by mean wait time.
> 
> (qemu) info sync-profile 3 
> Type               Object  Call site       Wait Time (s)         Count  
> Average (us)
> ------------------------------------------------------------------------------------
> condvar    0x560cc9909e50  cpus.c:1165          63.63428         16081       
> 3957.11
> condvar    0x560cc9909e50  cpus.c:1415           0.21074             2     
> 105371.07
> BQL mutex  0x560cc85a3fa0  util/rcu.c:269        0.20227            20      
> 10113.60
> ------------------------------------------------------------------------------------
> 
> (qemu) info sync-profile -m 3
> Type               Object  Call site       Wait Time (s)         Count  
> Average (us)
> ------------------------------------------------------------------------------------
> condvar    0x560cc9909e50  cpus.c:1415           0.21074             2     
> 105371.07
> BQL mutex  0x560cc85a3fa0  util/rcu.c:269        0.20227            21       
> 9632.00
> condvar    0x560cc9909e50  cpus.c:1165          71.92799         18167       
> 3959.27
> ------------------------------------------------------------------------------------
> 
> >, and one to coalesce all mutexes for the same call site?
> 
> I am not sure I understand. Do you mean to pass a specific call site,
> so that we coalesce all entries related to the call site's object?
> Or to keep the call sites separate, but only report entries related
> to that specific call site's object?

I would guess Paolo means that whether we can merge entries that have
the same call site but with different object addresses.  I copied one
example from the commit message of your patch 1:

Type               Object  Call site          Wait Time (s)         Count  
Average (us)
---------------------------------------------------------------------------------------
condvar    0x557ee3090e80  cpus.c:1084              1.69207          2916       
 580.27
condvar    0x557ee30ceb10  cpus.c:1084              1.43442          2404       
 596.68
...

IMHO merging of these two entries might be helpful when e.g. the
condvar used there is dynamically created/destroyed, then in this case
the object pointer might not that helpful, instead the statistics of
all the entries for the same call site might tell more.

Regards,

-- 
Peter Xu



reply via email to

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