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 12:29:24 +0000 Message-ID: <1426768160.2560.117.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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0493700143788778698==" Return-path: In-Reply-To: <550AB5B3.9020308@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 --===============0493700143788778698== Content-Language: en-US Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-gdKrPoK54wsFzM8Bv2st" --=-gdKrPoK54wsFzM8Bv2st Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-03-19 at 11:40 +0000, George Dunlap wrote: > On 03/19/2015 10:50 AM, Jan Beulich wrote: > >>>> On 19.03.15 at 11:03, wrote: > >> Nevertheless I see the value of doing so, and hence I think what we > >> could do would be to introduce a new hook in the scheduler interface, > >> called .init_pdata or .init_pcpu, and, in sched_*.c, split the > >> allocation and the initialization parts. The former will be handled > >> during CPU_UP_PREPARE, when allocation is possible, the latter during > >> CPU_STARTING, when we have more info available to perform actual > >> initializations. > >=20 > > Another alternative would be a new CPU_ALIVE (name subject to > > change) notification after interrupts got enabled. That would (as > > a follow-up cleanup) also allow the MTRR and microcode setup on > > the CPU to no longer need explicit calls (which look reversed > > anyway - surely we should update microcode before fiddling with > > MTRRs). >=20 > local_irq_enable() happens after setting the cpu as online in > cpu_online_map; not having the scheduler ready to actually schedule on > it at that time seems like it's asking for trouble. >=20 Right. > /me pokes around and thinks some more... >=20 So, if I can ask, how about my idea of splitting alloc_ and init_ parts of pCPU initialization ? :-) Regards, Dario --=-gdKrPoK54wsFzM8Bv2st 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 iEYEABECAAYFAlUKwSEACgkQk4XaBE3IOsR1IwCgkOOKSdE5EnnTbCAizRJhPjt4 AA0An2yl2iQz4NKxqhc7CByM7xNdh3IB =9pJ2 -----END PGP SIGNATURE----- --=-gdKrPoK54wsFzM8Bv2st-- --===============0493700143788778698== 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 --===============0493700143788778698==--