[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Notes on stubdoms and latency on ARM

Hi all,

Julien, Dario, George and I had a quick meeting to discuss stubdom
scheduling. These are my notes.

Description of the problem: need for a place to run emulators and
mediators outside of Xen, with low latency.

Explanation of what EL0 apps are. What should be their interface with
Xen? Could the interface be the regular hypercall interface? In that
case, what's the benefit compared to stubdoms?

The problem with stubdoms is latency and scheduling. It is not
deterministic. We could easily improve the null scheduler to introduce
some sort of non-preemptive scheduling of stubdoms on the same pcpus of
the guest vcpus. It would still require manually pinning vcpus to pcpus.

Then, we could add a sched_op hypercall to let the schedulers know that
a stubdom is tied to a specific guest domain. At that point, the
scheduling of stubdoms would become deterministic and automatic with the
null scheduler. It could be done to other schedulers too, but it will be
more work.

The other issue with stubdoms is context switch times. Volodymyr showed
that minios has much higher context switch times compared to EL0 apps.
It is probably due to GIC context switch, that is skipped for EL0 apps.
Maybe we could skip GIC context switch for stubdoms too, if we knew that
they are not going to use the VGIC. At that point, context switch times
should be very similar to EL0 apps.

Improve the null scheduler to enable decent stubdoms scheduling on
latency sensitive systems.
Investigate ways to improve context switch times on ARM.



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.