<div dir="ltr"><div><div><div>Hi, all:<br><br>Just want to update this in case any one want to use rtspin in Xen.<br><br></div>The tsc_mode makes little difference. The simulated one and the actual one differs in tens of cycles.<br>
<br></div>However, when I use rtspin to run the workload, the ratio is relative, not absolute.<br><br>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%.<br>
<br></div>My test environment is Xen, paravirtualized guest OS.<br><br>I don't know whether KVM will have the same issue or not.<br><div><div><br></div><div>Thanks.<br><br>Sisu<br></div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, May 5, 2013 at 2:11 PM, Sisu Xi <span dir="ltr"><<a href="mailto:xisisu@gmail.com" target="_blank">xisisu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>Hi, Björn:<br><br></div>Thanks for your reply!<br><div><div><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Sun, May 5, 2013 at 3:19 AM, Björn Brandenburg <span dir="ltr"><<a href="mailto:bbb@mpi-sws.org" target="_blank">bbb@mpi-sws.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On May 5, 2013, at 1:09 AM, Sisu Xi <<a href="mailto:xisisu@gmail.com" target="_blank">xisisu@gmail.com</a>> wrote:<br>
><br>
> I was trying to run some experiments in Litmus in a VM. However, all the number I got was negative for the task lateness.<br>
> And all jobs are showing 0 for the period, and shows CPU=-1.<br>
<br>
</div>Hi Sisu,<br>
<br>
these are two unrelated issues. First, negative lateness is perfectly fine. It just means that no deadlines were missed.<br>
<div><br></div></blockquote></div>oh, yes. That make sense. <br><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
> Here is the scripts to run experiments:<br>
> root@litmus1:~# cat 200_1_MPR_Dom1.sh<br>
> rtspin -s 0.98 8 10 100 &<br>
> rtspin -s 0.98 8 10 100 &<br>
> rtspin -s 0.98 8 10 100 &<br>
> rtspin -s 0.98 8 10 100 &<br>
> rtspin -s 0.98 8 10 100 &<br>
> st_trace 200_1_MPR_Dom1<br>
> killall rtspin<br>
<br>
</div>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.<br>
<div><br></div></blockquote><div><br></div></div><div>You are right, after I change the order, the task information is shown. And I will use process multiple files.<br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
><br>
> However, here is the result using st_job_stats<br>
> root@litmus1:~# st_job_stats st-200_1_MPR_Dom1-0.bin | head<br>
<br>
</div>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).<br>
<div><br></div></blockquote><div><br></div></div><div>I am not doing anything specific to the interrupt assignment. Just leave it as default.<br></div><div class="im"><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
> And the data on other cpus shows the same negative value for lateness..<br>
<br>
</div>Again, this is perfectly fine. lateness = absolute finish time - absolute deadline<br>
<div><br>
><br>
> In Xen, I am using tsc_mode=1, which is:<br>
> - tsc_mode=1 (always emulate). All rdtsc instructions are emulated;<br>
> this is the best choice when TSC-sensitive apps are running and<br>
> it is necessary to understand worst-case performance degradation<br>
> for a specific hardware environment.<br>
><br>
> this should be good for tsc-sensitive applications..<br>
><br>
> Any ideas?<br>
<br>
</div>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?<br>
<br></blockquote><div><br></div></div><div>Sure, I will double check that. thanks for the advise. <br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
<br></blockquote><div><br></div></div><div>Sure. I understand that. But it would not hurt to try it and see its results, right? :)<br></div><div class="im"><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Björn<br>
<br>
<br>
_______________________________________________<br>
litmus-dev mailing list<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org" target="_blank">litmus-dev@lists.litmus-rt.org</a><br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
</blockquote></div></div><br><br clear="all"><div class="im"><br>-- <br>Sisu Xi, PhD Candidate<br><br><a href="http://www.cse.wustl.edu/~xis/" target="_blank">http://www.cse.wustl.edu/~xis/</a><br>Department of Computer Science and Engineering<br>
Campus Box 1045<br>Washington University in St. Louis<br>One Brookings Drive<br>St. Louis, MO 63130
</div></div></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Sisu Xi, PhD Candidate<br><br><a href="http://www.cse.wustl.edu/~xis/" target="_blank">http://www.cse.wustl.edu/~xis/</a><br>Department of Computer Science and Engineering<br>
Campus Box 1045<br>Washington University in St. Louis<br>One Brookings Drive<br>St. Louis, MO 63130
</div>