From: David Gibson <david@gibson.dropbear.id.au>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Greg Kurz <groug@kaod.org>, qemu-devel@nongnu.org, qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] spapr_cpu_core: instantiate CPUs separately
Date: Tue, 17 Oct 2017 17:16:09 +1100 [thread overview]
Message-ID: <20171017061609.GL2776@umbus.fritz.box> (raw)
In-Reply-To: <20171016102638.6977381f@nial.brq.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2364 bytes --]
On Mon, Oct 16, 2017 at 10:26:38AM +0200, Igor Mammedov wrote:
> On Sat, 14 Oct 2017 20:33:37 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > On Fri, Oct 13, 2017 at 01:31:44PM +0200, Greg Kurz wrote:
> > > The current code assumes that only the CPU core object holds a
> > > reference on each individual CPU object, and happily frees their
> > > allocated memory when the core is unrealized. This is dangerous
> > > as some other code can legitimely keep a pointer to a CPU if it
> > > calls object_ref(), but it would end up with a dangling pointer.
> > >
> > > Let's allocate all CPUs with object_new() and let QOM frees them
> > > when their reference count reaches zero. This greatly simplify the
> > > code as we don't have to fiddle with the instance size anymore.
> > >
> > > Signed-off-by: Greg Kurz <groug@kaod.org>
> >
> > So, I'm pretty sure my first drafts of the core stuff did things this
> > waym and it got nacked, for QOM lifetime reasons that I never really
> > understood.
> From what I remember, Andreas would like to see composite CPU object
> allocated in one go and then its children initialized with object_initialize()
> so that no more allocation were needed.
Ah, ok.
> That potentially would benefit hotplug, since we could gracefully
> fail object creation early if there is not enough memory.
Yeah, it sounds nice, but I don't see how we can do it. In order to
do that the core object has to have enough space for all the threads,
which means we need both the size of each thread object and the number
of them. The size we have (and will be easier to handle after Igor's
cleanups). The number, we don't.
> But the way it's implemented currently doesn't really match that initial
> goal as array for threads is dynamically allocated later
> and then we need to dance around it with pointer arithmetic.
>
> BTW: almost any allocation failure in qemu currently
> is fatal so whether we fail on array alloc or on individual
> object_new() won't make any difference.
>
> I'd rather see this clean up merged as it simplifies code
> in these case.
Ok, works for me.
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-10-17 6:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-13 11:31 [Qemu-devel] [PATCH] spapr_cpu_core: instantiate CPUs separately Greg Kurz
2017-10-14 9:33 ` David Gibson
2017-10-15 20:57 ` Greg Kurz
2017-10-16 8:26 ` Igor Mammedov
2017-10-17 6:16 ` David Gibson [this message]
2017-11-06 15:03 ` Greg Kurz
2017-11-06 19:04 ` David Gibson
2017-11-14 7:59 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2017-11-19 23:17 ` David Gibson
2017-11-20 9:11 ` Greg Kurz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171017061609.GL2776@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=groug@kaod.org \
--cc=imammedo@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).