On Tue, 2018-10-09 at 12:59 +0200, Milan Boberic wrote:
Hi,
Hi Milan,
I'm testing Xen Hypervisor 4.10 performance on UltraZed-EG board with
carrier card.
I created bare-metal application in Xilinx SDK.
In bm application I:
- start triple timer counter (ttc) which generates
interrupt every 1us
- turn on PS LED
- call function 100 times in for loop (function that sets
some values)
- turn off LED
- stop triple timer counter
- reset counter value
Ok, I'm adding Stefano, Julien, and a couple of other people interested
in RT/lowlat on Xen.
I ran this bare-metal application under Xen Hypervisor with following
settings:
- used null scheduler (sched=null) and vwfi=native
- bare-metal application have one vCPU and it is pinned for pCPU1
- domain which is PetaLinux also have one vCPU pinned for pCPU0,
other pCPUs are unused.
Under Xen Hypervisor I can see 3us jitter on oscilloscope.
So, this is probably me not being familiar with Xen on Xilinx (and with
Xen on ARM as a whole), but there's a few things I'm not sure I
understand:
- you say you use sched=null _and_ pinning? That should not be
necessary (although, it shouldn't hurt either)
- "domain which is PetaLinux", is that dom0?
IAC, if it's not terrible hard to run this kind of test, I'd say, try
without 'vwfi=native', and also with another scheduler, like Credit,
(but then do make sure you use pinning).
When I ran same bm application with JTAG from Xilinx SDK (without Xen
Hypervisor, directly on the board) there is no jitter.
Here, when you say "without Xen", do you also mean without any
baremetal OS at all?
I'm curios what causes this 3us jitter in Xen (which isn't small
jitter at all) and is there any way of decreasing it?
Right. So, I'm not sure I've understood the test scenario either. But
yeah, 3us jitter seems significant. Still, if we're comparing with
bare-hw, without even an OS at all, I think it could have been expected
for latency and jitter to be higher in the Xen case.
Anyway, I am not sure anyone has done a kind of analysis that could
help us identify accurately from where things like that come, and in
what proportions.
It would be really awesome to have something like that, so do go ahead
if you feel like it. :-)
I think tracing could help a little (although we don't have a super-
sophisticated tracing infrastructure like Linux's perf and such), but
sadly enough, that's still not available on ARM, I think. :-/
