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: Wed, 18 Mar 2015 16:30:20 +0000 Message-ID: <1426696219.2560.55.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> <5509AEFF020000780006B465@mail.emea.novell.com> <5509A2FC.2010501@eu.citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3162726178726695377==" Return-path: In-Reply-To: <5509A2FC.2010501@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 --===============3162726178726695377== Content-Language: en-US Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xMVYDBc78Dd1HGdFqJxk" --=-xMVYDBc78Dd1HGdFqJxk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-03-18 at 16:08 +0000, George Dunlap wrote: > On 03/18/2015 03:59 PM, Jan Beulich wrote: > >>>> On 18.03.15 at 16:26, wrote: > >> In both cases there's a slight risk in using system_state to determine > >> whether to rely on cpu_data[] or not, because there's actually a windo= w > >> for each processor after system_state =3D=3D SYS_STATE_smp_boot where > >> cpu_data[] is *not* initialized, but it's not obvious from looking at > >> the data itself. If the callback mechanisms ever change order with th= e > >> cpu_data[] initializations in the future, we risk a situation where > >> credit2 silently regresses to using a single massive runqueue. > >=20 > > But such an ordering change is extremely unlikely, since the > > CPU_STARTING notification specifically tells you that the given > > CPU is now ready for normal use, which includes it having its > > topology related data set up. > Even if they look at init_pcpu() in credit2, they're > unlikely to know that cpu_to_socket() isn't valid until after > boot_secondary() has happened; and if they try it and boot it, > everything will seem to work perfectly for credit2 -- except that there > will be a single global runqueue. >=20 Agreed... and I'm still replying to your (George's) email, but just wanted to say that, for this, having system_state referenced from Credit2's code would help making it clear the fact that code has dependencies with the boot process, wouldn't it? > If you, Dario and I don't happen to catch it -- or don't happen to > remember the exact details of the constraints -- nobody may notice until > a year later. >=20 :-) > This is the point of having ASSERTs -- so that we don't have to worry > about remembering and catching all these crazy constraints. >=20 I'm all for finding a way for ASSERT()ing something meaningful to this effect. Regards, Dario --=-xMVYDBc78Dd1HGdFqJxk 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 iEYEABECAAYFAlUJqBsACgkQk4XaBE3IOsTtcwCgrecVcJ5jti/jodjsfdUwzQoQ H0wAoKdSwRfjUHBEK31oFc+adl2AJOq5 =6YTI -----END PGP SIGNATURE----- --=-xMVYDBc78Dd1HGdFqJxk-- --===============3162726178726695377== 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 --===============3162726178726695377==--