From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [DOC RFC] Heterogeneous Multi Processing Support in Xen Date: Wed, 1 Mar 2017 18:38:26 +0100 Message-ID: <1488389906.5548.166.camel@citrix.com> References: <1481135379.3445.142.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3424824907145325836==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Anastassios Nanos Cc: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= , Peng Fan , Stefano Stabellini , George Dunlap , Andrew Cooper , thkatsios@cslab.ece.ntua.gr, Xen Devel , Jan Beulich , Peng Fan List-Id: xen-devel@lists.xenproject.org --===============3424824907145325836== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-E0k2+FaW/uJcPaIoq7Kd" --=-E0k2+FaW/uJcPaIoq7Kd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2017-03-01 at 02:05 +0200, Anastassios Nanos wrote: > On Wed, Dec 7, 2016 at 8:29 PM, Dario Faggioli > wrote: > >=20 > > % Heterogeneous Multi Processing Support in Xen > > % Revision 1 > >=20 > > [...] > Hi all, >=20 Hello, > We are sending a branch[1] for comments on an initial implementation > of the above design document. Essentially it targets the ARM > big.LITTLE architecture.=20 > W00t ?!?! Just the fact that you did this, it is just great... thanks for that. > It would be great if you guys could comment > on the changes and provide some guidance for us to get it upstream. >=20 I'm sure up for that. I already know I won't have time to look at it until next week. But I'll make some space to look at the code then (I'm travelling, so I won't be furiously doing my own development anyway). > We have tested it on an odroid xu4 [2] and we are able to boot guests > with mixed vcpu affinities (big and LITTLE). >=20 Great to hear this too. > We are more than happy to submit patches once we address the issues > and come up with a review-able version of this implementation. >=20 Sure. So, from just a very quick glance, I can see an unique giant commit. This is ok for now, and I will look at it as it is. But, for sure, the first step toward making things reviewable, is to split the big patch in a series of smaller patches, as you probably know yourself already. :-) Since you're touching different component (as in, hypervisor, toolstack, build system, etc), splitting at the component boundaries is quite often something we want and ask for. Another criteria, orthogonal to the one cited above, is to separate patches that change architecture specific code, from patches that touches common areas. But, in general, the principle to follow is to split the patches at the "logical boundary", as this tries to explain: https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Break_down_= your_patches It's a rather difficult call, especially for changes like this. Therefore, as a first and fundamental step toward reviewability, I'd suggest start thinking at how to do the splitup. Anyway, I'll let you have my comments. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-E0k2+FaW/uJcPaIoq7Kd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJYtwcTAAoJEBZCeImluHPuyWIQAL8GVRb0DGxI1QXB9S/T8wXq 4NO22deKUxzfxwILAtrk2kM2Yjqt35JjZN9zM6UMrKRFYn+dDDKtZRYY3MB7vhH6 KaL16Ozj6xB7ZJH3lj35A5YzPgAZNFzEjwwBQvKz/U1bD5oAUaEWz27u8mPhrxQg xCzeWFxAYS7O4CtnWSAAUQa6ZzjVPJ56HmRyZ0tFuI2UN9JzdcZcFtAtdjUall9P XlV0vaPrPHnxhz/G6xsA9bvxEM7bwS6RV0+UL64pk7c0SDAwxoJtu4a6IqRU376Z pKTHxtBwKYE0jMeRsV5XbO12LcLsgcOALSK2o3gQgMDyywhSMIC46W7R410xIbyK 3B8ZERIV7ssWp1unYrhuc1mhfXeazIsHGHehNCAysm87urToO0AhmpTwJPsX/tP1 OoiT2tP1uO36uYXpdHT9UJDBLGDKlzlxJhwsnQAkLcqj8JyXALCvwq1lPLNiXFGD BFPm7VsoP5sl0iKc1hjFq81DDureJ73o735dOdlH7EPU/oF412rNDyMeBtgyH/LS wSF6X80bVQ+CXQ/ZDgRFg/bZNT1h5I5K3Bxpy946zHJxmk3SKycUNUorfPUbiInX kwojttAnBGKmscoLHfHilgvwMhDTF+rhY30k17DjUtWI3b701x+ZB42L4hYg21oM GIhWgK2RYz1VsdT3ZlB2 =khs0 -----END PGP SIGNATURE----- --=-E0k2+FaW/uJcPaIoq7Kd-- --===============3424824907145325836== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============3424824907145325836==--