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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Mon, 2017-06-19 at 11:36 -0700, Volodymyr Babchuk wrote:
> On 19 June 2017 at 10:54, Stefano Stabellini <sstabellini@xxxxxxxxxx>
> wrote:
> > True. However, Volodymyr took the time to demonstrate the
> > performance of
> > EL0 apps vs. stubdoms with a PoC, which is much more than most Xen
> > contributors do. Nodoby provided numbers for a faster ARM context
> > switch
> > yet. I don't know on whom should fall the burden of proving that a
> > lighter context switch can match the EL0 app numbers. I am not sure
> > it
> > would be fair to ask Volodymyr to do it.
> 
> Thanks. Actually, we discussed this topic internally today. Main
> concern today is not a SMCs and OP-TEE (I will be happy to do this
> right in XEN), but vcopros and GPU virtualization. Because of legal
> issues, we can't put this in XEN. And because of vcpu framework
> nature
> we will need multiple calls to vgpu driver per one vcpu context
> switch.
> I'm going to create worst case scenario, where multiple vcpu are
> active and there are no free pcpu, to see how credit or credit2
> scheduler will call my stubdom.
>
Well, that would be interesting and useful, thanks for offering doing
that.

Let's just keep in mind, though, that, if the numbers will turn out to
be bad (and we manage to trace that back to being due to scheduling),
then:
1) we can create a mechanism that bypasses the scheduler,
2) we can change the way stubdom are scheduled.

Option 2) is something generic, would (most likely) benefit other use
cases too, and we've said many times we'd be up for it... so let's
please just not rule it out... :-)

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel