From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dario Faggioli <dario.faggioli@citrix.com>
Subject: Re: RT-Xen on ARM
Date: Wed, 5 Jul 2017 10:42:57 +0200
Message-ID: <1499244177.7486.7.camel@citrix.com>
References: <b6de44dc-d4df-cda4-6a92-f39415bbc54f@epam.com>
 <CAENZ-+n5bTfNKSQE-B7V_QRY_LfVA60=waNgAMq5a1DVO0rhKQ@mail.gmail.com>
 <dac8b39c-c4cf-efe1-dc94-9d905cfa6590@epam.com>
 <CAENZ-+=syCWWSc+vGP-9FbLeULYXncZT6Qj64AEPv8NWRDMqTg@mail.gmail.com>
 <88185ae6-d1cf-898c-fe18-a569b0049230@epam.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1867454685481860165=="
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
 by lists.xenproject.org with esmtp (Exim 4.84_2)
 (envelope-from <prvs=352ca2d40=dario.faggioli@citrix.com>)
 id 1dSftu-0005pV-0I
 for xen-devel@lists.xenproject.org; Wed, 05 Jul 2017 08:43:10 +0000
In-Reply-To: <88185ae6-d1cf-898c-fe18-a569b0049230@epam.com>
List-Unsubscribe: <https://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <https://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xen.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xen.org>
To: Andrii Anisov <andrii_anisov@epam.com>, Meng Xu <xumengpanda@gmail.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
List-Id: xen-devel@lists.xenproject.org

--===============1867454685481860165==
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="=-GOr2hCFI6zHEVKvIuukb"

--=-GOr2hCFI6zHEVKvIuukb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2017-07-04 at 15:28 +0300, Andrii Anisov wrote:
> On 03.07.17 21:42, Meng Xu wrote:
> >=20
> > The RTDS uses the EDF scheduling, under which the priorities of the
> > VCPUs (or VMs) are dynamically changed based on their (absolute)
> > deadlines. This provides better real-time performance for the
> > *overall* system.
>=20
> In case we would have a driver domain and IC domain would draw to pv=C2=
=A0
> display baked by backend in a driver domain. Driver domain should be
> RT=C2=A0
> capable as well.
> So it seems two domains should be RT beside non-RT IVI domain.
>=20
Currently (and this is not changing anytime soon), the only way of
using different schedulers for different domains is by means of
cpupools.

I.e., you create, for instance, an RTDS pool, and a Credit or Credit2
pool. In the RTDS pool, you put the RT domains, so the IC domain and
the driver domains, and you subdivide resources between them according
to the utilization and latency requirements that each one of them has.

You then put all the non-RT domains in the other pool, and you control
their behavior via weighs, cap, pinning (etc).

Of course, this is just an example, and whether or not it is the best
way of going, as well as the specific parameters, really depends on the
characteristics of your platform and of your workload.

Trying to reason on as detailed as possible scenario, and then actually
testing and benchmarking every envisioned solution, is the only way to
actually tell what will work best.

As I said in the other email, I'm more than up discussing this, either
via email or in person (e.g., at the Summit).

Regards,
Dario
--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
--=-GOr2hCFI6zHEVKvIuukb
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

iQIcBAABCAAGBQJZXKaRAAoJEBZCeImluHPuudEQAJOWQgXXEZatSGTzxe95IPfA
ygAAPtNqlDYz1djvJBlw8yEdFdFENvmex0sV+uh4seuiRExuALpOskDKwHOsjEIM
a8dg7ervlIQ5FO1BDknvohCV62KzU556D1Oko4eLyb//Oc5RRj5lp28iEF5PeCXr
RU/znIM2t+vV8bmpF2N+3vjk4PbGGGDwCKtK3+RfpyLCxSHcvZm4P2NOKpS5xKzG
fxH0GzJmh0H/bQG/la2ZTNoPVFoQMWpJwCYhxQ6fJcbUFTfYsYHyVj857Seihr3+
COKelbp/2GVovH4B01yTU5n7trndecW/Onlm3AvxFFjpF+9N/AQIQT+uGrxdZyV9
ddm6dwdQS527hhrNoQVxKkr1288iJ2gqxn84kayrq/2gdLzel7sH1kIOM5+dNutK
dffYmuLTpKWxFRhuYD04uUE/5HGeHqi/QOnlH5RujwKQuUrIt8z/JQJ4/HePpO7+
ETmoc6JKpKM0zxuIQN+AVtXshauM/PgqVvpZ3XIYMft7RoaVK2JP0Tyl0UAxl4ZV
JhoO9gdpwNAT7VA8s0ksRRjYSHusxmkmJP+wMt1rqnWUG5CXOg1B8uPFqyhlisvu
nuUM2qTVBnhnnheItUAhPoV6UT3hAUYMBG11yGmI1iH9yMTkjZi6Wj2ZTo8PJjcb
kMpCkhY5Ze7VXEK8XEnG
=yiJH
-----END PGP SIGNATURE-----

--=-GOr2hCFI6zHEVKvIuukb--


--===============1867454685481860165==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

--===============1867454685481860165==--