All of lore.kernel.org
 help / color / mirror / Atom feed
From: Meng Xu <xumengpanda@gmail.com>
To: Andrii Anisov <andrii_anisov@epam.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: RT-Xen on ARM
Date: Mon, 9 Oct 2017 11:38:12 -0400	[thread overview]
Message-ID: <CAENZ-+=1RRxQu3AWCa6iTdWkRPyOUzStJX+dMMUh=8R2YD7Psw@mail.gmail.com> (raw)
In-Reply-To: <e7d861d2-5e4f-4907-1521-6e03d2e5c0a8@epam.com>

Hi Andrii,

I'm sorry for replying to this thread late. I was busy with a paper
deadline until last Saturday morning.

I saw Dario's thorough answer which explains the high-level idea of
the real-time analysis that is the theoretical foundation of the
analysis tool, e.g., CARTs.
Hopefully, he answered your question.
If not, please feel free to ask.

I just added some very quick comment about your questions/comments below.

On Thu, Sep 28, 2017 at 5:18 AM, Andrii Anisov <andrii_anisov@epam.com> wrote:
> Hello,
>
>
> On 27.09.17 22:57, Meng Xu wrote:
>>
>> Note that:
>> When you use gEDF scheduler in VM or VMM (i.e., Xen), you should use
>> MPR2 model
>
> I guess you mean DMPR in CARTS terms.
>
>>   to compute the resource interface (i.e., VCPU parameters).
>> When you use pEDF scheduler, you should use PRM model to compute.
>>>
>>>      - 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], 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.

The number of VCPUs can be larger than the number of PCPUs.

>
>> If you are considering VCPUs with very low utilization, you may use
>> PRM model to compute each VCPU's parameters; after that, you can treat
>> these VCPUs as tasks, create another xml file, and ask CARTS to
>> compute the resource interface for these VCPUs.
>
> Sounds terrible for getting it scripted :(

If you use python to parse the xml file, it should not be very
difficuly. Python has api to parse the xml. :)

>>
>> (Unfortunately, the current CARTS implementation does not support
>> mixing MPR model in one XML file, although it is supported in theory.
>> This can be worked around by using the above approach.)
>>
>>> For pEDF at both VMM and
>>> domain level, my understanding is that the os_scheduler represents XEN,
>>> and
>>> VCPUs are represented by components with tasks running on them.
>>
>> Yes, if you analyze the entire system that uses one type of scheduler
>> with only one type of model (i.e., PRM or MPR2).
>>
>> If you mixed the scheduling algorithm or the interface model, you can
>> compute each VM or VCPU's parameters first. Then you treat VCPUs as
>> tasks and create another XML which will be used to compute the number
>> of cores to schedule all these VCPUs.
>>
>>>      - I did not get a concept of min_period/max_period for a
>>> component/os_scheduler in CARTS description files. If I have them
>>> different,
>>> CARTS gives calculation for all periods in between, but did not provide
>>> the
>>> best period to get system schedulable.
>>
>> You should set them to the same value.
>
> Ok, how to chose the value for some taskset in a component?

Tasks' periods and execution time depends on the tasks' requirement.
As Dario mentioned, if a sensor needs to process every 100ms, the
sensor task's period is 100ms. Its execution time is the worst-case
execution time of the sensor task.

As to the component (or VM)'s period, it's better to be smaller than
its tasks' periods. Usually, I may want to set to a value divisible by
its tasks' periods.
You may try different values for components' periods, because the
VCPU's bandwidth (budget/period) will be different for different
components' periods.
You can choose the component's period that produces a smaller VCPU's
bandwidth, which may help make VCPUs easiler to be scheduled on PCPUs.

Best,

Meng


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

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

  parent reply	other threads:[~2017-10-09 15:38 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-03 11:03 RT-Xen on ARM Andrii Anisov
2017-07-03 13:03 ` Wei Liu
2017-07-03 13:26   ` Andrii Anisov
2017-07-03 13:35 ` Meng Xu
2017-07-03 14:58   ` Andrii Anisov
2017-07-03 18:42     ` Meng Xu
2017-07-04 12:28       ` Andrii Anisov
2017-07-04 15:12         ` Meng Xu
2017-07-05  8:29           ` Dario Faggioli
2017-07-07 18:29             ` Meng Xu
2017-07-12  6:13               ` Dario Faggioli
2017-07-05  8:42         ` Dario Faggioli
2017-07-05  8:51       ` Dario Faggioli
2017-07-07 18:43         ` Meng Xu
2017-07-07 18:46           ` Meng Xu
2017-07-10  9:22           ` Andrii Anisov
2017-08-01 11:02     ` Andrii Anisov
2017-08-18 20:43       ` Meng Xu
2017-08-21  8:07         ` Andrii Anisov
2017-08-21  8:16           ` Andrii Anisov
2017-08-22  2:02             ` Meng Xu
2017-09-27 12:37               ` Andrii Anisov
2017-09-27 13:57                 ` Meng Xu
2017-09-27 14:37                   ` Andrii Anisov
2017-09-27 19:57                     ` Meng Xu
2017-09-28  9:18                       ` Andrii Anisov
2017-09-28 16:01                         ` Dario Faggioli
2017-09-28 17:56                           ` Dario Faggioli
2017-09-29 10:24                           ` Andrii Anisov
2017-10-09 15:38                         ` Meng Xu [this message]
2017-08-22  1:58           ` Meng Xu
2017-08-21  8:38         ` Andrii Anisov
2017-08-22  2:19           ` Meng Xu
2017-07-05  7:33 ` Dario Faggioli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAENZ-+=1RRxQu3AWCa6iTdWkRPyOUzStJX+dMMUh=8R2YD7Psw@mail.gmail.com' \
    --to=xumengpanda@gmail.com \
    --cc=andrii_anisov@epam.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.