Xen project Mailing List

On Sun, Nov 29, 2015 at 8:44 AM, Meng Xu <xumengpanda@xxxxxxxxx> wrote:

2015-11-29 11:27 GMT-05:00 Dario Faggioli <dario.faggioli@xxxxxxxxxx>:
> On Sun, 2015-11-29 at 10:38 -0500, Meng Xu wrote:
>>
>>
>> 2015-11-29 7:46 GMT-05:00 Yu-An(Victor) Chen <chen116@xxxxxxx>:
>> > Hi Meng,
>> >
>> Hi,
>>
>> >
>> > So I will rewrite my setup here again, but this time I shorten the
>> > period and budget for RTDS like you suggested:
>> >
>> Nice! :-)
>>
>>
>> > -----------------------------------------------------------------
>> > ------------------------------------------------------------
>> >
>> (I like this line, BTW. :-D)
>> >
>> >
>> > for xen-credit : 2vms (both vm are given 8 vCPUs) sharing 8 cores
>> > (cpu 0-7) using credit scheduler(both with weight of 800 and
>> > capacity of 400)
>> > for xen-rtds: 2 vms (both vm are given 8 vCPUs) sharing 8 cores
>> > (cpu0-7) using RTDS (both with period of 4000(4ms) and budget of
>> > 2000(2ms)))
>> > In both setup, dom0 is using 1 core from cpu 8-15
>> >
>> > In both setup:
>> >
>> > I loaded VM2 with constant running task with total utilization of 4
>> > cores.
>> > and in VM1 I run iterations of tasks of total utilization rate of 1
>> > cores, 2 cores, 3 cores, 4 cores, and then record their
>> > schedulbility.
>> > -----------------------------------------------------------------
>> > ------------------------------------------------------------
>> >
>> > So st_jobs_stats for the missed deadline jobs are:
>> >
>> > trial #1 composed of 2 tasks: total tasks utilization rate = 1
>> >
>> > (period, exe, deadline)=(21ms,12.023ms,21ms) -> miss all deadline
>> > (period, exe, deadline)=(100ms,37.985ms,100ms) -> no miss
>> >
>> yes, this is the information I need and we can solve the mystery
>> now...
>> Let's look at this task:
>> (period, exe, deadline)=(21ms,12.023ms,21ms) -> miss all deadline
>> Its utilization is 12.023 / 21 ~= 0.5614;
>> Your VCPU utilization is only 2ms / 4ms = 0.5
>> So even when this task is pinned to one VCPU, it will still miss
>> deadline because it has only one thread. :-)
>>
> Mmmm... As I said many times, I don't remember much of all those RT
> schedulability formulas, but, is really that simple?

Ah, let me clarify...
It is not that simple. ;-) I just simplify it, hoping it can simplify
the problem and highlight the possible reason.

> I mean, if the in-
> guest scheduling algorithm is global (e.g., global-EDF), the task could
> migrate, couldn't it?

Yes. If these partial VCPUs happen to be scheduled "sequentially", the
OS inside VM can migrate the task and make the task keep running. But
that is not the worst-case for the OS.

The worst case for the OS to schedule one task is that all of these
VCPUs are released at the same time, are schedulable as early as
possible in the first period and scheduled as late as possible in the
second period, which will create the largest starvation period to the
VM.
So in the worst case, you won't be able to schedule a task with
utilization U on k VCPUs with utilzation U, no matter how large k is.
(Think about that these k VCPUs are always scheduled at the same
time.)

The detailed illustration of the worst case scenario is at Arvind's
paper: http://link.springer.com/article/10.1007%2Fs11241-009-9073-x
My latest journal paper
(http://link.springer.com/article/10.1007%2Fs11241-015-9223-2) tighten
the resource supply bound function of the MPR model. I believe the
equations are too boring to most of people in the mailing list.

So let's avoid the complex equations here. ;-)

To Yu-An,
The basic idea is, as Dario mentioned in the previous email, that the
configuration of VCPUs are important to provide the schedulability of
tasks inside VM. Especially, if you are doing research in RT, you need
to (maybe have to) know the RT scheduling theory. :-)

>
> Is it really the case that you can never schedule tasks with U greater
> than the smaller U of the various vCPUs (which seems to me to be what
> you're implying)?
No. In the worst case, it is.
Because the VCPUs are created with the "similar" release time, they
may very likely be scheduled concurrently and fall intoÂ the so-called
"worst case" (which is just worse case for sequential task) in an idle
system.

>
> Anyway...
>

OK. I can understand... Hope my explanation won't cause more confusion. :-D

Best,

Meng

-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

Re: [Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms