[LITMUS^RT] 0 period, negative lateness for recorded tasks -- Sisu

[Andrea Bastoni]

Hi Sisu,

On Mon, May 13, 2013 at 5:14 AM, Sisu Xi <xisisu at gmail.com> wrote:
> Hi, all:
>
> Just want to update this in case any one want to use rtspin in Xen.
>
> The tsc_mode makes little difference. The simulated one and the actual one
> differs in tens of cycles.
>
> However, when I use rtspin to run the workload, the ratio is relative, not
> absolute.
>
> For example, if a VCPU is given 40% of share, and I run rtspin with
> wcet/period=0.5 in it, it will actually run 40% * 50% = 20%.
>
> My test environment is Xen, paravirtualized guest OS.
>
> I don't know whether KVM will have the same issue or not.

Thanks for the report.
KVM is not a bare-hw virtualizator, and you don't have the options to
assign VCPU shares there. (But you can try to use cgroups to achieve a
similar result.) Also, as already pointed out, under KVM the TSC is
mostly not reliable.

Thanks,
- Andrea

>
> Thanks.
>
> Sisu
>
>
> On Sun, May 5, 2013 at 2:11 PM, Sisu Xi <xisisu at gmail.com> wrote:
>>
>> Hi, Björn:
>>
>> Thanks for your reply!
>>
>> On Sun, May 5, 2013 at 3:19 AM, Björn Brandenburg <bbb at mpi-sws.org> wrote:
>>>
>>> On May 5, 2013, at 1:09 AM, Sisu Xi <xisisu at gmail.com> wrote:
>>> >
>>> > I was trying to run some experiments in Litmus in a VM. However, all
>>> > the number I got was negative for the task lateness.
>>> > And all jobs are showing 0 for the period, and shows CPU=-1.
>>>
>>> Hi Sisu,
>>>
>>> these are two unrelated issues. First, negative lateness is perfectly
>>> fine. It just means that no deadlines were missed.
>>>
>> oh, yes. That make sense.
>>
>>>
>>> > Here is the scripts to run experiments:
>>> > root at litmus1:~# cat 200_1_MPR_Dom1.sh
>>> > rtspin -s 0.98 8 10 100 &
>>> > rtspin -s 0.98 8 10 100 &
>>> > rtspin -s 0.98 8 10 100 &
>>> > rtspin -s 0.98 8 10 100 &
>>> > rtspin -s 0.98 8 10 100 &
>>> > st_trace 200_1_MPR_Dom1
>>> > killall rtspin
>>>
>>> This is the wrong order. When a task is launched, its parameters and PID
>>> are written to the sched_trace stream. If no tracer is present, the
>>> information is discarded.  You need to start tracing prior to launching real
>>> time tasks.
>>>
>>
>> You are right, after I change the order, the task information is shown.
>> And I will use process multiple files.
>>
>>>
>>> >
>>> > However, here is the result using st_job_stats
>>> > root at litmus1:~# st_job_stats st-200_1_MPR_Dom1-0.bin | head
>>>
>>> You always need to look at all trace files together. Don't just look at
>>> one core's file, as tasks may migrate under global schedulers, and since
>>> release events may happen on any core (unless you are careful with the
>>> interrupt assignment).
>>>
>>
>> I am not doing anything specific to the interrupt assignment. Just leave
>> it as default.
>>
>>
>>>
>>> > And the data on other cpus shows the same negative value for lateness..
>>>
>>> Again, this is perfectly fine. lateness = absolute finish time - absolute
>>> deadline
>>>
>>> >
>>> > In Xen, I am using tsc_mode=1, which is:
>>> > - tsc_mode=1 (always emulate). All rdtsc instructions are emulated;
>>> >    this is the best choice when TSC-sensitive apps are running and
>>> >    it is necessary to understand worst-case performance degradation
>>> >    for a specific hardware environment.
>>> >
>>> > this should be good for tsc-sensitive applications..
>>> >
>>> > Any ideas?
>>>
>>> I'd be *very* careful in making any claims about the accuracy of timing
>>> in a VM. Are you 100% sure that there are no timing glitches due to the
>>> emulation? Are you sure that overhead measurements based on emulated TSCs
>>> even meaningfully reflect the actual overheads?
>>>
>>
>> Sure, I will double check that. thanks for the advise.
>>
>>>
>>> We have never used LITMUS^RT in a VM for benchmarking (we run LITMUS^RT
>>> in VMs primarily to aid with debugging). If you want good measurements, it's
>>> better to run the kernel on bare metal.
>>>
>>
>> Sure. I understand that. But it would not hurt to try it and see its
>> results, right?  :)
>>
>>
>>>
>>> - Björn
>>>
>>>
>>> _______________________________________________
>>> litmus-dev mailing list
>>> litmus-dev at lists.litmus-rt.org
>>> https://lists.litmus-rt.org/listinfo/litmus-dev
>>
>>
>>
>>
>> --
>> Sisu Xi, PhD Candidate
>>
>> http://www.cse.wustl.edu/~xis/
>> Department of Computer Science and Engineering
>> Campus Box 1045
>> Washington University in St. Louis
>> One Brookings Drive
>> St. Louis, MO 63130
>
>
>
>
> --
> Sisu Xi, PhD Candidate
>
> http://www.cse.wustl.edu/~xis/
> Department of Computer Science and Engineering
> Campus Box 1045
> Washington University in St. Louis
> One Brookings Drive
> St. Louis, MO 63130
>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>