From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v2 2/2] sched_credit2.c: runqueue_per_core code Date: Thu, 19 Mar 2015 13:00:59 +0000 Message-ID: <1426770055.2560.131.camel@citrix.com> References: <20150313181109.GA3179@gmail.com> <55032C85.6090805@citrix.com> <550336EE.60909@eu.citrix.com> <5506DF40020000780006A407@mail.emea.novell.com> <5506D1E1.8050404@eu.citrix.com> <5506E11F020000780006A426@mail.emea.novell.com> <1426616308.32500.98.camel@citrix.com> <55093DD1020000780006B1F2@mail.emea.novell.com> <1426668836.2560.13.camel@citrix.com> <55099940.7080007@eu.citrix.com> <1426697366.2560.65.camel@citrix.com> <5509B066.5050302@eu.citrix.com> <1426759435.2560.104.camel@citrix.com> <550AB812020000780006B872@mail.emea.novell.com> <550AB5B3.9020308@eu.citrix.com> <1426768160.2560.117.camel@citrix.com> <550AC295.2080906@eu.citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3942528338299784979==" Return-path: In-Reply-To: <550AC295.2080906@eu.citrix.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Cc: Andrew Cooper , "xen-devel@lists.xen.org" , George Dunlap , "JBeulich@suse.com" , "uma.sharma523@gmail.com" List-Id: xen-devel@lists.xenproject.org --===============3942528338299784979== Content-Language: en-US Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dIp7mXi6v0Dij20fCX+T" --=-dIp7mXi6v0Dij20fCX+T Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-03-19 at 12:35 +0000, George Dunlap wrote: > On 03/19/2015 12:29 PM, Dario Faggioli wrote: > > So, if I can ask, how about my idea of splitting alloc_ and init_ parts > > of pCPU initialization ? :-) >=20 > Architecturally, from some points of view it makes sense > It does, doesn't it? That's why I like it: it fixes the issue we have, but in an architecturally sensible and non hackish way, IMO. > from > other points of view, it would be nicer not to multiply callbacks and > make the interface more complicated. >=20 I see what you mean, and I agree. Well, from an arithmetic point of view, this will allow us to get rid of the .global_init hook, so the numbers of hook will be unchanged! ;-P Jokes apart, complexity has to be added to solve the issue, it's either this patch or the one from earlier in the thread which checked system_state=3D=3DSYS_STATE_boot in csched2_alloc_pdata (with the added >= =3D SYS_STATE_active for the cpupool case, of course). As you said in the first place, reducing dependencies, or at least making them easier to track, it's of some value, and I think the alloc_/init_ splitting approach goes in that direction. > But from a practical point of view, this path is already more work than > I was expecting it to be, so I don't think we should spend *too* much > time looking for alternatives. If that seems like the best option at > the moment, then I'm fine with it. >=20 Great. I'll put a proper series together, and let's see how it'll look like. :-) Thanks and Regards, Dario --=-dIp7mXi6v0Dij20fCX+T 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 iEYEABECAAYFAlUKyIcACgkQk4XaBE3IOsSgmgCfZRUpqWEXwMWcZhcuJPj0vXbs IW4An0oLYGbTr42IIAM/5huafl73uoe8 =r22w -----END PGP SIGNATURE----- --=-dIp7mXi6v0Dij20fCX+T-- --===============3942528338299784979== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3942528338299784979==--