Re: [ARM] Native application design and discussion (I hope)

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3370 bytes --]

On Tue, 2017-04-11 at 13:32 -0700, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Stefano Stabellini wrote:
> > 
> > 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:
> > 
>
IMO, this stubdom way, is really really really interesting! :-)

> > 1) Determinism: a stubdom servicing a given guest needs to be
> > scheduled
> >    immediately after the guest vcpu traps into Xen. It needs to
> >    deterministic.
>
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.
> >    This is probably the most important missing thing at the moment.
> > 
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
> >    agaist the domain it is servicing. Otherwise it's not fair.
> > 
Absolutely.

> > 3) Visibility: stub domains and vcpus should be marked differently
> > from other
> >    vcpus as not to confuse the user. Otherwise "xl list" becomes
> >    confusing.
> > 
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.
> 
> 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.
> 
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
-- 
<<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)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel