[LITMUS^RT] Running LITMUS-RT on ARM64

[Björn Brandenburg]

> On 28. Aug 2017, at 16:28, Andrii Anisov <andrii_anisov at epam.com> wrote:
> 
> 
> On 28.08.17 16:57, Björn Brandenburg wrote:
>> Perhaps it is related to virtualized time? Can you reproduce the effect on bare metal (i.e., on native LITMUS^RT without any virtualization layer)?
> I think it is not about virtualized time.
> I guess I could explain task execution time stretching with the VCPU nature in a virtualized system. I.e. VCPUs are also scheduled, and it might be vcpu with a task running to be scheduled out from physical CPU, then scheduled in. So task execution time increases. But I can not explain to myself an execution time reduction.

Good point. However, looking at the trace, something funny appears to be going on with the system time/timing: the runtime of each job seems to depend on which of the tasks is scheduled first, which it obviously shouldn’t depend on. 

> Anyway I should also learn about rtspin internals and sort out what was said to me here[1].
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2017-08/msg02351.html

Thanks for the pointer. Meng’s explanation hints at a problem related to timekeeping, which of course can be circumvented by simply executing a fixed amount of work, but his description of rtspin is not quite right.

rtspin does NOT compare time stamps relative to wall clock time. Instead, it queries the kernel for the amount of CPU time that the process has consumed and simulates the workload based on that. See here:

	https://github.com/LITMUS-RT/liblitmus/blob/master/bin/rtspin.c#L217

The cputime() function used here is defined in src/clocks.c and uses CLOCK_THREAD_CPUTIME.

	https://github.com/LITMUS-RT/liblitmus/blob/master/src/clocks.c#L14

So if an rtspin process gets preempted, it will NOT count the time that it is preempted as execution time. Here’s the “done spinning” condition that clearly shows this:

	https://github.com/LITMUS-RT/liblitmus/blob/master/bin/rtspin.c#L211

I’m pretty sure this works correctly on bare metal. I’m attaching a trace of two rtspin instances launched as follows:

	setsched P-FP
	rtspin -w -p 1 -o 2 -q  5 -s 1 1 20 10 &
	rtspin -w -p 1      -q 10 -s 1 5 10 10 &

In the trace you can see that the WCET=5ms task exhibits a response time of 6ms whenever it is preempted by the WCET=1ms task. Also note how little execution-time variation the jobs are exhibiting. 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: schedule_host=rts5_scheduler=P-FP_trace=preempt-test.pdf
Type: application/pdf
Size: 28113 bytes
Desc: not available
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20170828/fcc2150f/attachment-0001.pdf>
-------------- next part --------------


Andrii, can you please check that this basic example works as expected?

Meng, in your experience, is rtspin showing strange behaviour related to preemptions if LITMUS^RT is being virtualized? This would suggest that LITMUS^RT’s execution time tracking is broken under (para-)virtualization… 

Thanks,
Björn