On 2013-04-28 15:53, Andreas Färber wrote: > Am 28.04.2013 15:03, schrieb Jan Kiszka: >> On 2013-04-28 13:22, Andreas Färber wrote: >>> Necessary to change the name of ICCDevice's parent object field. >>> >>> Signed-off-by: Andreas Färber <afaer...@suse.de> --- Could any of >>> the APIC experts please review whether I'm touching any hot >>> path? Not sure if this was a mix of pre- and post-QOM code or >>> intentional... Thanks. > >> How "hot" does it have to be before we notice the type check >> overhead? Did anyone already measure this, given that they are >> getting very common now? > > Heh, if I had a conclusive benchmark I wouldn't ask. ;)
Do object_class_dynamic_cast & friends show up higher in profiling results when using your patch with an emulated APIC? > > In general init, reset and MMIO were considered cold paths in this > regard. Timer and interrupt code paths by contrast I've usually tried > to spare. ...but not in this patch. There are things like "deliver", "get_interupt", "accept", and the APIC MMIO handlers are stressed at least once per IRQ as well (EOI). When emulating in userspace. > >> But none of the touched functions are used during normal operation >> when the KVM APIC is active. With emulated APIC, they are >> frequently used, of course. > > Where in doubt, we could just use (APICCommonState *) or a macro > hiding that. Actually, I would prefer making the typical type check (class up- and down-casts) so light-weight that we do not have to worry. Something that ideally boils down to comparing two magic numbers inline. Jan
signature.asc
Description: OpenPGP digital signature