From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWSM5-0001Tf-O0 for qemu-devel@nongnu.org; Sun, 28 Apr 2013 10:13:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWSM4-0006aB-N7 for qemu-devel@nongnu.org; Sun, 28 Apr 2013 10:13:29 -0400 Received: from mout.web.de ([212.227.15.3]:56886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWSM4-0006a5-CA for qemu-devel@nongnu.org; Sun, 28 Apr 2013 10:13:28 -0400 Message-ID: <517D2E75.4050500@web.de> Date: Sun, 28 Apr 2013 16:13:09 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1367148131-1440-1-git-send-email-afaerber@suse.de> <517D1E19.1030905@web.de> <517D29E8.40507@suse.de> In-Reply-To: <517D29E8.40507@suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2WXPQKHKALMUMKHFPEDPV" Subject: Re: [Qemu-devel] [PATCH RFC qom-cpu-next] apic: QOM'ify APICCommonState casts List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: imammedo@redhat.com, gleb@redhat.com, qemu-devel@nongnu.org, anthony@codemonkey.ws, ehabkost@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2WXPQKHKALMUMKHFPEDPV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2013-04-28 15:53, Andreas F=C3=A4rber wrote: > Am 28.04.2013 15:03, schrieb Jan Kiszka: >> On 2013-04-28 13:22, Andreas F=C3=A4rber wrote: >>> Necessary to change the name of ICCDevice's parent object field. >>> >>> Signed-off-by: Andreas F=C3=A4rber --- Could any o= f >>> 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. >=20 >> 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? >=20 > 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? >=20 > 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. =2E..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. >=20 >> 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. >=20 > 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 ------enig2WXPQKHKALMUMKHFPEDPV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF9LngACgkQitSsb3rl5xSr9ACdEXjD1Ge2FaIUivbprRB+GDky eo4An12kH3HyaB9BoY0Ttc1hY0j1g4ht =aXEu -----END PGP SIGNATURE----- ------enig2WXPQKHKALMUMKHFPEDPV--