From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v3 for Xen 4.6 1/4] xen: enable per-VCPU parameter settings for RTDS scheduler Date: Tue, 7 Jul 2015 16:39:04 +0200 Message-ID: <1436279944.22672.104.camel@citrix.com> References: <1435545899-22751-1-git-send-email-chong.li@wustl.edu> <1435545899-22751-2-git-send-email-chong.li@wustl.edu> <559BB101020000780008D371@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3999744678750016679==" Return-path: In-Reply-To: <559BB101020000780008D371@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Chong Li , Chong Li Cc: Sisu Xi , george.dunlap@eu.citrix.com, xen-devel@lists.xen.org, Meng Xu , Jan Beulich , dgolomb@seas.upenn.edu List-Id: xen-devel@lists.xenproject.org --===============3999744678750016679== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qE5CXpu8gOIspMGVc+lX" --=-qE5CXpu8gOIspMGVc+lX Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-07-07 at 09:59 +0100, Jan Beulich wrote: > >>> On 29.06.15 at 04:44, wrote: > > --- a/xen/common/Makefile > > +++ b/xen/common/Makefile > > @@ -31,7 +31,6 @@ obj-y +=3D rbtree.o > > obj-y +=3D rcupdate.o > > obj-y +=3D sched_credit.o > > obj-y +=3D sched_credit2.o > > -obj-y +=3D sched_sedf.o > > obj-y +=3D sched_arinc653.o > > obj-y +=3D sched_rt.o > > obj-y +=3D schedule.o >=20 > Stray change. Or perhaps the file doesn't build anymore, in which case > you should instead have stated that the patch is dependent upon the > series removing SEDF. >=20 This indeed does not belong in here. And of course, things should build... So, Chong, either deal with SEDF as well, if basing your patches on a tree where it is still there, or base on top of my patches, ignore it, but state the dependency, as Jan is asking. > > @@ -1157,8 +1158,75 @@ rt_dom_cntl( > > + case XEN_DOMCTL_SCHEDOP_putvcpuinfo: > > + spin_lock_irqsave(&prv->lock, flags); > > + for( index =3D 0; index < op->u.v.nr_vcpus; index++ ) > > + { > > + if ( copy_from_guest_offset(&local_sched, > > + op->u.v.vcpus, index, 1) ) > > + { > > + rc =3D -EFAULT; > > + break; > > + } > > + if ( local_sched.vcpuid >=3D d->max_vcpus > > + || d->vcpu[local_sched.vcpuid] =3D=3D NULL ) > > + { > > + rc =3D -EINVAL; > > + break; > > + } > > + svc =3D rt_vcpu(d->vcpu[local_sched.vcpuid]); > > + svc->period =3D MICROSECS(local_sched.s.rtds.period); > > + svc->budget =3D MICROSECS(local_sched.s.rtds.budget); >=20 > Are all input values valid here? >=20 That's a good point, actually. Right now, SEDF does some range enforcement, by means of these values: #define PERIOD_MAX MILLISECS(10000) /* 10s */ #define PERIOD_MIN (MICROSECS(10)) /* 10us */ #define SLICE_MIN (MICROSECS(5)) /* 5us */ Chong, it probably makes sense to (in a separate patch), introduce something like this in RTDS too (with SLICE_MIN-->BUDGET_MIN), and then use them, in this patch, for sanity checking the input. It also makes sense to check and enforce budget<=3Dperiod, IMO. About the specific values, I'm open to proposals. I think something like the SEDF's one is fine. Meng? Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-qE5CXpu8gOIspMGVc+lX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlWb5IgACgkQk4XaBE3IOsStqgCdF9lJGnEcgTLP5jsEoC4cKhJS zKkAoKj3SYIp+daIk/T2wCKtwpGxvs4b =1X7l -----END PGP SIGNATURE----- --=-qE5CXpu8gOIspMGVc+lX-- --===============3999744678750016679== 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 --===============3999744678750016679==--