[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