qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus lis


From: David Gibson
Subject: Re: [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list
Date: Mon, 25 Jul 2016 16:09:04 +1000
User-agent: Mutt/1.6.2 (2016-07-01)

On Wed, Jul 20, 2016 at 09:01:11AM +0200, Peter Krempa wrote:
> On Wed, Jul 20, 2016 at 11:00:05 +1000, David Gibson wrote:
> > On Tue, Jul 19, 2016 at 01:52:40PM +0200, Peter Krempa wrote:
> > > On Mon, Jul 18, 2016 at 19:19:19 +1000, David Gibson wrote:
> > > > The spapr implementation of query-hotpluggable-cpus builds the list of
> > > > hotpluggable cores from the end (most removed from the list head)
> > > > because that's the easiest way with a singly linked list.  Because it
> > > > also traverses the possible CPU cores starting from low indexes the
> > > > resulting list has the cpu cores listed in reverse order by core-id.
> > > > 
> > > > That's not generally harmful, but it means the output from "info
> > > > hotpluggable-cpus" is a little harder to read than it could be.
> > > > 
> > > > Therefore, traverse the cpus in reverse order so that the final list
> > > > ends up in increasing-core-id order.
> > > 
> > > To make this interface usable with in-order hotplug the ordering of the
> > > entries should be codified in the schema documentation. (see my response
> > > on the cover letter for justification).
> > 
> > I'm not really sure what you mean by this.
> 
> Currently the order of entries in reply of query-hotpluggable-cpus is
> arbitrary as this patch hints.
> 
> If qemu won't support arbitrary order hotplug but libvirt should be able
> to use the new interface, then the order of replies of
> query-hotpluggable-cpus need to corelate (in a documented fashion) with
> the order we need to plug the cpus in. By not documenting any order
> libvirt can just guess it (by reimplementing the algorithm in qemu).
> 
> I've pointed this out in a sub-thread of the cover-letter.

So, based on Peter's comments (and others) I've concluded that the
cpu-add implementation in terms of the new interface isn't really
useful.

However, I think this re-ordering is still a good idea, because:
  * It makes info hotpluggable-cpus easier to read in the HMP

  * Although we certainly need a better approach to handling hotplug +
    NUMA, correcting the order should allow the existing NUMA
    interface to work with only as much guesswork in libvirt as we
    already have.

  * We haven't released a qemu with query-hotpluggable-cpus yet, so we
    shouldn't need version conditions in order to use the order.

For that reason I've tentatively merged this patch into ppc-for-2.7.
It would be good to get an R-b or A-b from someone before I send a
pull request (which I'm hoping to do tomorrow).

-- 
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: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]