On Thu, 2017-09-28 at 12:18 +0300, Andrii Anisov wrote:
> > >      - Could you please provide an example input xml for CARTS
> > > described a
> > > system with 2 RT domains with 2 VCPUs each, running on a 2PCPUs,
> > > with gEDF
> > > scheduling at VMM level (for XEN based setup).
> > 
> > Hmm, if you use the gEDF scheduling algorithm, this may not be
> > possible. Let me explain why.
> > In the MPR2 model, it computes the interface with the minimum
> > number
> > of cores. To get 2 VCPUs for a VM, the total utilization (i.e.,
> > budget
> > / period) of these two VCPUs must be larger than 1.0. Since you ask
> > for 2 domains, the total utilization of these 4 VCPUs will be
> > larger
> > than 2.0, which are definitely not schedulable on two cores.
> 
> Well, if we are speaking about test-cases similar to described in
> [1], 
>
Missing the link?

> where the whole real time tasks set utilization is taken from 
> 1.1...(PCPU*1)-0.1, there is no problem with having VCPU number
> greater 
> than PCPUs. For sure if we take number of domains  more that 1.
> 
I may miss/have misunderstood some of the background information, but
anyway. Also, I've been exposed to the supply/demand concepts that are
the basis of Meng's CARTS tool, during my PhD on this things, but it's
been a while, so bear with me.

Point is, if you have 4 vCPUs in total (2 domains with 2 each), and 2
pCPUs, they can't run all the time all together. The choices are
between a general purpose scheduler, or an RT one.

The GP scheduler --like Credit1 or Credit2, if you are on Xen-- will
give you fairness, but without any precise temporal guarantee. This
means that, in this case, each vCPU will be given the chance to run for
1/2 CPU capacity (at there are 2 CPUs, 4 vCPUs total, i.e., 2/4=1/2).
You can influence this with weights, but that's still "not real-time".

I.e., if you say that d1v0 and d1v1 have double the weights of d2v0 and
d2v1, if 2 is the total available CPU capacity, d1's vCPUs will run for

Now, let's say that, in d1, there is a critical real-time application
that absolutely needs to read the status of a sensor every 10ms. Is
there a set of weights able to provide you with the guarantee that it
will always be able to, whatever it is that the other vCPUs are doing?

Well, no, there isn't. And this is where RTDS becomes interesting. So,
is there a way to tell to RTDS that you want to be sure that d1 will
have a chance to run every 10ms? Yes, there is: you give to it a period
of 10ms. Now you need to esteem how much computation time d1's vCPUs
require (for reading that sensors, but, let's say, also for doing other
stuff, since it's a 2 vCPUs VM). Let's assume that you're quite
confident that it will be enough to giving 20% overall capacity to each
vCPU. This means budget for d1v0 and d1v1 will be 2ms (as 2/10*100=20).

Now, there is another domain, and it may host applications with real-
time requirements as well, here's where things become interesting.
According to what I remember from SMP real-time scheduling theory, you
just can't assume that giving d2v0 and d2v1 budget and period of 80ms
and 100ms, respectively, will result in a schedulable system, even
though you have 2 CPUs, and 2/10+2/10+80/100+80/100=2 (for Meng, I'm
talking in general, about the fact that, under gEDF, with M CPUs, U<M
is necessary but not sufficient, but I haven't done the math for this
specific case :-P).

And here's where tools like CARTS may be of great help. So, basically,
if also the applications that you want to run in d2 have their own
timing requirement, you use those to come up with an indication of the
period the VM's vCPUs need to have. Then you use a tool, passing all
these information to it as parameters (not that I've never used CARTS,
so I don't know what parameters it actually takes, I'm talking in
general), and the tool gives you the scheduling parameter at each
level: OS scheduler --which would be Linux/Android, inside the VMs--
and hypervisor scheduler --which would be the budget and period of the
vCPUs to configure in RTDS.

But you can't (or at least, I don't think) expect the tools to just
tell you "how to set parameters for scheduling 4 vCPUs on 2 pCPUs",
without also telling it what you want/need to achieve. So, basically,
you have to define the term "schedule", in the above sentence.

Otherwise, which I think is what Meng is telling you when he says "this
may not be possible", I guess the tool will try to see if it is
possible to schedule 4 vCPUs over 2 pCPUs, in such a way that whatever
real-time activities, running on those 4 vCPUs, will all and always
meet their deadline... and the answer will (probably?) be 'no'.

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)