From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afyWq-0005dQ-Kl for qemu-devel@nongnu.org; Tue, 15 Mar 2016 19:37:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afyWo-0003pE-Dx for qemu-devel@nongnu.org; Tue, 15 Mar 2016 19:37:32 -0400 Date: Wed, 16 Mar 2016 10:33:37 +1100 From: David Gibson Message-ID: <20160315233337.GJ9032@voom> References: <1457672078-17307-1-git-send-email-bharata@linux.vnet.ibm.com> <1457672078-17307-7-git-send-email-bharata@linux.vnet.ibm.com> <20160314112523.1c43461f@nial.brq.redhat.com> <20160315091401.GB13176@in.ibm.com> <20160315093428.GB9032@voom> <20160315144637.38f190f4@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yr/DzoowOgTDcSCF" Content-Disposition: inline In-Reply-To: <20160315144637.38f190f4@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH v2 6/9] spapr: CPU core device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: mjrosato@linux.vnet.ibm.com, thuth@redhat.com, pkrempa@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru, armbru@redhat.com, agraf@suse.de, qemu-devel@nongnu.org, borntraeger@de.ibm.com, qemu-ppc@nongnu.org, Bharata B Rao , pbonzini@redhat.com, afaerber@suse.de, mdroth@linux.vnet.ibm.com --yr/DzoowOgTDcSCF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 15, 2016 at 02:46:37PM +0100, Igor Mammedov wrote: > On Tue, 15 Mar 2016 20:34:28 +1100 > David Gibson wrote: > > On Tue, Mar 15, 2016 at 02:44:01PM +0530, Bharata B Rao wrote: > > > On Mon, Mar 14, 2016 at 11:25:23AM +0100, Igor Mammedov wrote: =20 > > > > On Fri, 11 Mar 2016 10:24:35 +0530 > > > > Bharata B Rao wrote: [snip] > > > > > + if (!core->oc) { > > > > > + error_setg(&local_err, "cpu_model property isn't set"); > > > > > + goto out; > > > > > + } > > > > > + > > > > > + core_dt_id =3D object_property_get_int(OBJECT(dev), "core", = &local_err); > > > > > + if (local_err) { > > > > > + goto out; > > > > > + } > > > > > + > > > > > + if (core_dt_id % smt) { > > > > > + error_setg(&local_err, "invalid core id %d\n", core_dt_i= d); > > > > > + goto out; > > > > > + } > > > > > + > > > > > + core_id =3D core_dt_id / smt; > > > > > + if (core_id < 0 || core_id >=3D spapr_max_cores) { > > > > > + error_setg(&local_err, "core id %d out of range", core_d= t_id); > > > > > + goto out; > > > > > + } =20 > > > > maybe due to nameing it's a bit confusing, > > > > what's difference between core_id and core_dt_id? =20 > > >=20 > > > core_dt_id is the device tree IDs that we use with PowerPC cores. Thi= s is > > > what we use with "core" property of CPU_CORE. Since core_dt_id doesn't > > > grow contiguously (Eg. it will be 0, 8, 16 etc for SMT8 guest on a PO= WER8 host), > > > I am translating that to contiguous integer core_id so that I can > > > store the pointer of the realized core in the appropriate slot of > > > spapr->cpu_cores[] array. =20 > >=20 > > So, I see why the distinction is there, but it is kinda confusing. > > I'm wondering if we could do away with the spapr->cores array entirely > > and instead just access the core objects via the QOM tree - QOM > > "arrays" (i.e. properties named like foo[NNN]) can be sparse, so > > there's no need to allocate dense ids. > Wouldn't be lookups for duplicate in QOM tree take O(N^2) > when hot-plugging N cpus? With the present QOM implementation, yes, although I know Paolo has made noises about changing that to a hash table. > It should be less with sorted array at least. It would, but I doubt the O(N^2) will actually be a problem with realistic numbers of cpus. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --yr/DzoowOgTDcSCF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW6JvRAAoJEGw4ysog2bOSyikQAMJUK+VFHqjZ5uocDwZRLtEE mz4yH6TvWS67Q+y7HuQ8fJeHGRqRF2jZ1HpGvBfQYuR8n1HsWiK4Ex0n/QGKPP/t goe0CPvfe5mLMFkJ6hHwRlsLTohtCFYo5ndIEW6GupQ0ZY2H5UuFtrIOxKsG55Te dcyWsJWwcBCiWhfdY1o5qRwRfHIaqEtTGhX1zEvIfJ9fuDTIrrju67rCETrQvVR3 XawtDQgoewt0DMe6daYvx0SVrOas5oTPtMprh4URWagTrV3Q/QMIaf7jl4XtNTCw S/PnDentNDMCZqvFJRKFR8WvxH5VEwqT4tNAA8ROJ57P486KUTYB8Yq4oaR77nEG ICUry88s6yfICGsO8jZ23r3zGnI48rt0iEA/CexAEKRl4CMGkKAK6gZbNy4UcKxA bhqrb1MY4s4FBXBnztw+umuv5YO/uObNplAtT1j5RNJRcOniu48QHgWwhMfLZTuw BMCTKXske5Zd9lMsMC/WlXYwcRn4DGvoU9FxvDgqLrD1JXK8mJ18imKAdqDrtZBX 3S4YRznp048GzqlYpuOCGruA7dOAAdH0t/6sIF5u84x/bFKw2/3etCWMalTAUKLL 1xAOH38FeCY/JjXMNDBGSeQBDMHLmIRmk3+ZgsBGhjKlIrKR7CN83CfJ5LKZ6Qje mLfMcosbDfzXoOOrIzqN =g2YI -----END PGP SIGNATURE----- --yr/DzoowOgTDcSCF--