qemu-devel
[Top][All Lists]
Advanced

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

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


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH for-1.5 0/9] Disable expensive QOM cast debugging for official releases
Date: Fri, 10 May 2013 16:22:08 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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
address@hidden                 http://www.aurel32.net



reply via email to

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