[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggab
From: |
David Gibson |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list |
Date: |
Tue, 26 Jul 2016 11:13:52 +1000 |
User-agent: |
Mutt/1.6.2 (2016-07-01) |
On Mon, Jul 25, 2016 at 10:14:18AM +0200, Igor Mammedov wrote:
> On Mon, 25 Jul 2016 16:09:04 +1000
> David Gibson <address@hidden> wrote:
>
> > 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.
> I've talked with Peter and meanwhile (till we have sane NUMA interface)
> libvirt will be guessing ids based on query-hotpluggable-cpus output
> sorted by socket/core/thread-id, so forward/reverse order won't really
> matter to it.
>
> Forward sorting is fine wrt 'info hotpluggable-cpus', however it might
> be better to do sorting in HMP callback so that each target won't have
> to do it nor regress command output in future or introduce another
> ordering.
>
> Considering that ordering affects only HMP won't require any compat
> glue even if it's not fixed in 2.7 release.
Hm, ok, I'll drop this patch.
>
> >
> > 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
signature.asc
Description: PGP signature
- Re: [Qemu-ppc] [Qemu-devel] [RFC 2/2] qmp: Implement cpu-add in terms of query-hotpluggable-cpus when available, (continued)
- [Qemu-ppc] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list, David Gibson, 2016/07/18
- Re: [Qemu-ppc] [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list, Peter Krempa, 2016/07/19
- Re: [Qemu-ppc] [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list, David Gibson, 2016/07/19
- Re: [Qemu-ppc] [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list, Peter Krempa, 2016/07/20
- Re: [Qemu-ppc] [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list, David Gibson, 2016/07/21
- Re: [Qemu-ppc] [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list, Igor Mammedov, 2016/07/21
- Re: [Qemu-ppc] [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list, Greg Kurz, 2016/07/21
- Re: [Qemu-ppc] [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list, David Gibson, 2016/07/25
- Re: [Qemu-ppc] [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list, Igor Mammedov, 2016/07/25
- Re: [Qemu-ppc] [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list,
David Gibson <=
Re: [Qemu-ppc] [RFC 0/2] cpu-add compatibility for query-hotpluggable-cpus implementations, Peter Krempa, 2016/07/18
Re: [Qemu-ppc] [RFC 0/2] cpu-add compatibility for query-hotpluggable-cpus implementations, David Gibson, 2016/07/18