[LITMUS^RT] Running LITMUS-RT on ARM64

Andrii Anisov andrii_anisov at epam.com
Thu Sep 21 15:26:33 CEST 2017


Hello Björn,

On 21.09.17 13:08, Björn Brandenburg wrote:
> Hi Andrii,
>
> this is what I’m seeing; seems to be ok:
>
> objdump -t rtspin | grep loop
> 0000000000402ee0 l     F .text	0000000000000065              loop
> 0000000000403040 l     F .text	0000000000000084              loop_once_with_mem
> 00000000004031b0 l     F .text	000000000000012d              loop_for
Yep, it is here.


Ok, we have following values:

> In 1 ms 124415 loops.
> In 10 ms 1835007 loops.
> In 100 ms 30228892 loops.
> In 1 s 301964990 loops.

In fact I would take the value from 1s evaluation (divided by 1000), in your case 301964. Then run `rtspin -l -a0` and then adjust it manually to get minimal error.

> When running the configuration loop (on an Intel Xeon CPU E5-2450 @ 2.10GHz):
>
> ./rtspin -a0
> Probe 4096 loops for 1 ms:
> Probe 8192 loops for 1 ms:
> Probe 16384 loops for 1 ms:
> Probe 32768 loops for 1 ms:
> Probe 65536 loops for 1 ms:
> Probe 131072 loops for 1 ms:
> 98304 loops elapsed in 0.00078678131103515625 s
> 114688 loops elapsed in 0.00091290473937988281 s
> 122880 loops elapsed in 0.00098991394042968750 s
> 126976 loops elapsed in 0.00100708007812500000 s
> 124928 loops elapsed in 0.00100111961364746094 s
> 123904 loops elapsed in 0.00098490715026855469 s
> 124416 loops elapsed in 0.00100708007812500000 s
> 124160 loops elapsed in 0.00098299980163574219 s
> 124288 loops elapsed in 0.00098085403442382812 s
> 124352 loops elapsed in 0.00098705291748046875 s
> 124384 loops elapsed in 0.00092506408691406250 s
> 124400 loops elapsed in 0.00092005729675292969 s
> 124408 loops elapsed in 0.00092291831970214844 s
> 124412 loops elapsed in 0.00092983245849609375 s
> 124414 loops elapsed in 0.00091719627380371094 s
> 124415 loops elapsed in 0.00092101097106933594 s
> In 1 ms 124415 loops.
But something is going wrong in this probation. You can see pretty big 
execution time deviation which turned binary search in a completely 
wrong direction. Maybe some specific runtime optimizations of this CPU.

One more change I missed during patches reordering is here [1]. This 
also might be the cause. Could you please give it a try?

> For comparison, the old cputime()/TSC-based loop usually achieves an error of less than 0.002%.
Well, from my understanding, the cputime()/TSC-based loop is self 
balancing due to its timekeeping nature so it tends to show better 
numbers in debug cases.


> Here I’m getting "In 1 ms 441849 loops.”, which results in an error between 2% and 3%, which is much better, but still not that great.
Yep, in this case I'd do manual adjustments of the value. I.e. 
`441849*1.025 *≈*  453000`

[1] 
https://github.com/aanisov/liblitmus/commit/0bfe5c08e15aca0505bdc769f8f348c88952df21
-- 

*Andrii Anisov*





More information about the litmus-dev mailing list