From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [ARM] Native application design and discussion (I hope) Date: Wed, 12 Apr 2017 20:13:42 +0200 Message-ID: <1492020822.3287.33.camel@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7575925968479351713==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Stefano Stabellini Cc: Volodymyr Babchuk , Julien Grall , Artem Mygaiev , george.dunlap@citrix.com, Xen Devel List-Id: xen-devel@lists.xenproject.org --===============7575925968479351713== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-PlKI9I0IyTTuQ+/IqU3j" --=-PlKI9I0IyTTuQ+/IqU3j Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-04-11 at 13:32 -0700, Stefano Stabellini wrote: > On Fri, 7 Apr 2017, Stefano Stabellini wrote: > >=20 > > This is the most difficult problem that we need to solve as part of > > this > > work. It is difficult to have the right answer at the beginning, > > before > > seeing any code. If the app_container/app_thread approach causes > > too > > much duplication of work, the alternative would be to fix/improve > > stubdoms (minios) until they match what we need. Specifically, > > these > > would be the requirements: > >=20 > IMO, this stubdom way, is really really really interesting! :-) > > 1) Determinism: a stubdom servicing a given guest needs to be > > scheduled > > =C2=A0=C2=A0=C2=A0immediately after the guest vcpu traps into Xen. It n= eeds to > > =C2=A0=C2=A0=C2=A0deterministic. > Something like this is in my plan since long time. Being able to / having help for making it happen would be *great*! So, if I'm the scheduler, can you tell me exactly when a vcpu blocks waiting for a service from the vcpu of an app/stubdom (as opposed to, going to sleep, waiting for other, unrelated, event, etc), and which one? If yes... That'd be a good start. > > The stubdom vcpu has to be scheduled on the same pcpu. > > =C2=A0=C2=A0=C2=A0This is probably the most important missing thing at = the moment. > >=20 That's interesting --similar to what I had in mind, even-- but needs thinking. E.g., if the stubdom/app is multi-vcpu, which of its vcpu would you schedule? And how can we be sure that what will run on that vcpu of the stubdom is _exactly_ the process that will deal with the request the "real gust" is waiting on? TBH, this is much more of an issue if we think of doing something like this for driver domain too, while in the stubdom case it indeed shouldn't be impossible, but still... (And stubdoms, especially minios ones, are the ones I know less, so bear with me a bit.) > > 2) Accounting: memory and cpu time of a stubdom should be accounted > > =C2=A0=C2=A0=C2=A0agaist the domain it is servicing. Otherwise it's not= fair. > >=20 Absolutely. > > 3) Visibility: stub domains and vcpus should be marked differently > > from other > > =C2=A0=C2=A0=C2=A0vcpus as not to confuse the user. Otherwise "xl list"= becomes > > =C2=A0=C2=A0=C2=A0confusing. > >=20 Well, may seem unrelated, but will you schedule the subdom _only_ in this kind of "donated time slots" way? > > 1) and 2) are particularly important. If we had them, we would not > > need > > el0 apps. I believe stubdoms would be as fast as el0 apps too. >=20 > CC'ing George and Dario. I was speaking with George about this topic, > I'll let him explain his view as scheduler maintainer, but he > suggested > to avoid scheduler modifications (all schedulers would need to be > taught to handle this) and extend struct vcpu for el0 apps instead. >=20 Yeah, thanks Stefano. I'm back today after being sick for a couple of days, so I need to catch up with this thread, and I will. In general, I like the idea of enhancing stubdoms for this, and I'll happily participate in design and development of that. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-PlKI9I0IyTTuQ+/IqU3j 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 iQIcBAABCAAGBQJY7m5WAAoJEBZCeImluHPu8VkP/iJBxkA69+E3jcrjCmAAQJLT VZEBI/CngBWUbKBUELx1oC8JfR54YeaUCdgnqEUvTcO2dPvZ6rL15/70TF+2o4AS l5HH04XqLpvBbdDAn/eJIJN4Dr0iD0trZ0XX3HTUr6m3CQsyHye1Xx/NVwRkPBUH XTuf5BVIDW5nzOWB1YLJpLj2m4zq3fqwq19rlpt69hIE5IhvrrVgC0+U0p8+H4UA rO3zEQn9NayENLz56a/qYY6Mcq/ZxJoxUFfBNwh7FoCl4a/8sdbJOzN6c54wdOS1 AZJXX4ea/M7jcuH2JhymAdLXV3HhHfOg+XvraoGMmGUI1GV8NVwnT2nRUaXgTmTQ vYtHBiaOGhFDXu0OsLHzhywXEkG5yz8+S2Ttv1DdPqxId6jtwyJjxtXHK4H0EBVg GFrhfV5ys6Spr1DFsopnqp9kiKs3/PoqP8RIgTpiSQB8dkrchN+RGDpvMVWEaTEO ZPk/SAGYRwaHW1LCAbnzHnRDt589po/FmiQOQkjWFOtdpV+Z4u0WNI+vhs0s4UVN 4eWFGQlHNy7BSmc/5OeVhd20L2UMjsV0YW+gc8lL738TU4Wn96LvHnhKX0ul/aoy jxVTePQFhMyxnVRqTuXFS2b0eosj/GyrwloBUE0vg7TWKHxIq0aZ2MV+n5/IQoYk XClv3i5KU4HaxH4ffLWo =021o -----END PGP SIGNATURE----- --=-PlKI9I0IyTTuQ+/IqU3j-- --===============7575925968479351713== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============7575925968479351713==--