From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSLnj-00034m-AJ for qemu-devel@nongnu.org; Wed, 27 Jul 2016 06:10:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSLnd-0005TS-8R for qemu-devel@nongnu.org; Wed, 27 Jul 2016 06:10:54 -0400 Received: from 3.mo7.mail-out.ovh.net ([46.105.34.113]:40301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSLnc-0005SI-U8 for qemu-devel@nongnu.org; Wed, 27 Jul 2016 06:10:49 -0400 Received: from player694.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id E6919100CDF1 for ; Wed, 27 Jul 2016 12:10:43 +0200 (CEST) Date: Wed, 27 Jul 2016 12:06:17 +0200 From: Greg Kurz Message-ID: <20160727120617.7c3eb34d@kaod.org> In-Reply-To: <20160725060131.GJ24621@voom.fritz.box> References: <146918576946.26293.7740314135850382852.stgit@bahia.lan> <20160725060131.GJ24621@voom.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/dEyEwGo86dSls6Zv7JCH4o8"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] [PATCH RFC] spapr: disintricate core-id from DT semantics List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Igor Mammedov , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Bharata B Rao --Sig_/dEyEwGo86dSls6Zv7JCH4o8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le Mon, 25 Jul 2016 16:01:31 +1000, David Gibson a =C3=A9crit : > On Fri, Jul 22, 2016 at 01:10:36PM +0200, Greg Kurz wrote: > > The goal of this patch is to have a stable core-id which does not depend > > on any DT related semantics, which involve non-obvious computations on > > modern PowerPC server cpus. > >=20 > > With this patch, the DT core id is computed on-demand as: > >=20 > > (core-id / smp_threads) * smt > >=20 > > where smt is the number of threads per core in the host. > >=20 > > This formula should be consolidated in a helper since it is needed in > > several places. =20 >=20 > It's a little odd you node this but don't do so. >=20 I was too busy packing for holidays already :) and I think the consolidation work can be addressed in followup patches. Cheers from Brittany, under the rain. -- Greg > > Other uses for core-id includes: compute a stable cpu_index (which > > allows random order hotplug/unplug without breaking migration) and > > NUMA. > >=20 > > Signed-off-by: Greg Kurz > > --- > >=20 > > It was first suggested here: > >=20 > > https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg01727.html > >=20 > > and as option 1) in the following discussion on IRC: > >=20 > > imammedo, basically the options are: 1) change core-ids to be > > 0, 1, .. n and compute cpu_index as core_id * threads + thread#, or > > 2) leave core-ids as they are and calculate cpu_index as > > core-id / smt * threads + thread# > >=20 > > It is based on David's ppc-for-2.7 branch (commit bb6268f35f457). > >=20 > > It is lightly tested but I could at least do in-order > > hotplug/unplug. =20 >=20 > I think this is basically the right approach, and I've applied to > ppc-for-2.7. Here's my plan for what to do about all this id stuff: >=20 > 1. Merge this to ppc-for-2.7 (done) > 2. Assuming there are now show-stoppers in testing, send a pull > request tomorrow > 3. Once this is merged, try to get Igor's series (or a respin of it) > in ASAP. >=20 > I'm hoping that will give us good-enough hotplug for 2.7. >=20 > In the 2.8 timeframe, I want to: > 4. Disconnect KVM vcpu ID from dt_id, instead calculate it from (now > stable) cpu_index > 5. Remove dt_id as a cpu field - instead just compute DT ids from > the (now stable) cpu_index when we build the DT > 6. (for new machine type versions) Change DT ID assignment, so it > no longer depends on kvmppc_smt_threads(). The current scheme > means that migration between hosts with different native SMT > values won't work, which is unfortunate. I suspect there may be > other problems with any real situation where that's the case, > but nontheless it's a silly restriction. >=20 > Nice to have but bigger scope things for 2.8: > 7. Update archs to they *all* call cpu_exec_init() / cpu_exec_exit() > at realize / unrealize time instead of init / finalize time. > 8. Update all archs and machines to use stable cpu_index >=20 --Sig_/dEyEwGo86dSls6Zv7JCH4o8 Content-Type: application/pgp-signature Content-Description: Signature digitale OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAleYh5oACgkQAvw66wEB28KoIQCeJiWa4sF4EpuOaEm5V1OZDSbH X4wAnjz4QlpHsE3vS27CPjwsubleWtwr =XNBu -----END PGP SIGNATURE----- --Sig_/dEyEwGo86dSls6Zv7JCH4o8--