[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH v2 6/9] spapr: CPU core device
From: |
David Gibson |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH v2 6/9] spapr: CPU core device |
Date: |
Wed, 16 Mar 2016 10:33:37 +1100 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Tue, Mar 15, 2016 at 02:46:37PM +0100, Igor Mammedov wrote:
> On Tue, 15 Mar 2016 20:34:28 +1100
> David Gibson <address@hidden> 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:
> > > > On Fri, 11 Mar 2016 10:24:35 +0530
> > > > Bharata B Rao <address@hidden> wrote:
[snip]
> > > > > + if (!core->oc) {
> > > > > + error_setg(&local_err, "cpu_model property isn't set");
> > > > > + goto out;
> > > > > + }
> > > > > +
> > > > > + core_dt_id = 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_id);
> > > > > + goto out;
> > > > > + }
> > > > > +
> > > > > + core_id = core_dt_id / smt;
> > > > > + if (core_id < 0 || core_id >= spapr_max_cores) {
> > > > > + error_setg(&local_err, "core id %d out of range",
> > > > > core_dt_id);
> > > > > + goto out;
> > > > > + }
> > > > maybe due to nameing it's a bit confusing,
> > > > what's difference between core_id and core_dt_id?
> > >
> > > core_dt_id is the device tree IDs that we use with PowerPC cores. This 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 POWER8
> > > 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.
> >
> > 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.
--
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
signature.asc
Description: PGP signature
[Qemu-ppc] [RFC PATCH v2 5/9] cpu: Abstract CPU core type, Bharata B Rao, 2016/03/10
[Qemu-ppc] [RFC PATCH v2 7/9] spapr: CPU hotplug support, Bharata B Rao, 2016/03/10
[Qemu-ppc] [RFC PATCH v2 8/9] xics, xics_kvm: Handle CPU unplug correctly, Bharata B Rao, 2016/03/10
[Qemu-ppc] [RFC PATCH v2 9/9] spapr: CPU hot unplug support, Bharata B Rao, 2016/03/10