On Fri, May 10, 2013 at 03:30:17PM +0200, Paolo Bonzini wrote: > Il 10/05/2013 15:23, Andreas Färber ha scritto: > > Am 10.05.2013 15:08, schrieb Paolo Bonzini: > >> Il 10/05/2013 15:01, Anthony Liguori ha scritto: > >>> 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 CPUs were the only reason, we could simply change those inlines and > > ENV_GET_CPU() macro to use a C cast. No complicated interface scenarios > > requiring a dynamic cast are used for CPUs so far to my knowledge. > > Almost nothing really requires a dynamic cast in QEMU. Only interface > casts do, and there's just a couple of uses of interfaces. > > And I wrote in the cover letter that what I want is really avoid the > need for "fast casts" in the hot paths. > > Can you guys actually read the commit messages? > > > Either way, it would be nice to see the call sites of those > > most-impacting dynamic casts! So far I held back my APIC RFC since I'm > > not sure how to reproducibly profile things. > > It's interrupts (both sending and returning from them). >
More precisely in target-ppc/excp_helper.c: - in ppc_hw_interrupt - in helper_store_msr - in do_rfi (called from helper_rfi) - in helper_msgsnd Sot it's at least twice per interruption, which means doing hash table lookup and string comparison through glib a few hundred to a few thousand times per second. Before the QOMification, it was a simple pointer access. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net