Re: [Qemu-devel] [PATCH for-1.5 0/9] Disable expensive QOM cast debugging for official releases

[Aurelien Jarno]

On Fri, May 10, 2013 at 09:27:28AM -0500, Anthony Liguori wrote:
> Paolo Bonzini <address@hidden> writes:
> 
> > Il 10/05/2013 15:01, Anthony Liguori ha scritto:
> >> Paolo Bonzini <address@hidden> writes:
> >> 
> >>> Cast debugging can have a substantial cost (20% or more, measured by
> >>> Aurelien on qemu-system-ppc64).
> >> 
> >> [Needs citation]
> >
> > Sure: http://permalink.gmane.org/gmane.comp.emulators.qemu/210830
> >
> >  49,73%  perf-10672.map           [.] 0x7f7853ab4e0f
> >  13,23%  qemu-system-ppc64        [.] cpu_ppc_exec
> >  13,16%  libglib-2.0.so.0.3200.4  [.] g_hash_table_lookup
> >   8,18%  libglib-2.0.so.0.3200.4  [.] g_str_hash
> >   2,47%  qemu-system-ppc64        [.] object_class_dynamic_cast
> >   1,97%  qemu-system-ppc64        [.] type_is_ancestor
> >   1,05%  libglib-2.0.so.0.3200.4  [.] g_str_equal
> >
> > That's ~27%.
> >
> >>> Instead of adding special-cased "fast
> >>> casts" in the hot paths, we can just disable it in releases.  At the
> >>> same time, add tracing facilities that simplify the analysys of those
> >>> problems that cast debugging would reveal.
> >> 
> >> I'd prefer not to disable but instead focus on improving performance.
> >
> > For 1.5?  This is a regression in 1.5 due to more and more usage of
> > foo_env_on_cpu.
> 
> If this is a regression, then we should be able to show:
> 
> 1) workload XYZ gets X in 1.4 and Y in 1.5
> 
> 2) applying your series demonstrates that we go back to X performance

I will work on that.

> I'm not convinced this is a true set of statements.  13% of time spent
> doing casts could simply suggest that the vcpu is largely idle and has
> nothing better to do.

It's not in KVM, but in the QEMU case. The emulated CPU was fully loaded
during this perf trace, and the qemu-system-ppc64 process was taking
about 100% of the host CPU. This means that this 13% of the time doing
cast can be used to emulate more instructions.

> At any rate, given (1), we can at least try some other less invasive
> approachs to fixing the problem.  Just removing the unnecessary cast
> might end up doing it.

We have changed a pointer access in a hot path (and more are likely to
come as far as I know) to a complex function. The correct way to fix
that is to remove the complex function.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net