On Fri, May 10, 2013 at 09:27:28AM -0500, Anthony Liguori wrote: > Paolo Bonzini <pbonz...@redhat.com> writes: > > > Il 10/05/2013 15:01, Anthony Liguori ha scritto: > >> Paolo Bonzini <pbonz...@redhat.com> 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 aurel...@aurel32.net http://www.aurel32.net