Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

[Julien Grall <julien.grall@xxxxxxx>]

On 24/04/17 22:41, Volodymyr Babchuk wrote:
> Julien,
Hi Volodymyr,

> > > > > We will also need another type of application: one which is
> > > > > periodically called by XEN itself, not actually servicing any domain
> > > > > request. This is needed for a
> > > > > coprocessor sharing framework scheduler implementation.
> > > > EL0 apps can be a powerful new tool for us to use, but they are not the
> > > > solution to everything. This is where I would draw the line: if the
> > > > workload needs to be scheduled periodically, then it is not a good fit
> > > > for an EL0 app.
> > > From my last conversation with Volodymyr I've got a feeling that notions
> > > "EL0" and "XEN native application" must be pretty orthogonal.
> > > In [1] Volodymyr got no performance gain from changing domain's
> > > exception level from EL1 to EL0.
> > > Only when Volodymyr stripped the domain's context  abstraction (i.e.
> > > dropped GIC context store/restore) some noticeable results were reached.
> >
> > Do you have numbers for part that take times in the save/restore? You
> > mention GIC and I am a bit surprised you don't mention FPU.
> I did it in the other thread. Check out [1]. The most speed up I got
> after removing vGIC context handling
Oh, yes. Sorry I forgot this thread. Continuing on that, you said that 
"Now profiler shows that hypervisor spends time in spinlocks and p2m code."
Could you expand here? How the EL0 app will spend time in p2m code?

Similarly, why spinlocks take time? Are they contented?

> > I would have a look at optimizing the context switch path. Some ideas:
> >         - there are a lot of unnecessary isb/dsb. The registers used by the
> > guests only will be synchronized by eret.
> I have removed (almost) all of them. No significant changes in latency.
>
> >         - FPU is taking time to save/restore, you could make it lazy
> This also does not takes much time.
>
> >         - It might be possible to limit the number of LRs saved/restored
> > depending on the number of LRs used by a domain.
> Excuse me, what is LR in this context?
Sorry I meant GIC LRs (see GIC save/restore code). They are used to list 
the interrupts injected to the guest. All of they may not be used at the 
time of the context switch.
> You can take a look at my context switch routines at [2].
I had a quick look and I am not sure which context switch you exactly 
used as you split it into 2 helpers but also modify the current one.
Could you briefly describe the context switch you do for EL0 app here?


> [1] http://marc.info/?l=xen-devel&m=149088856116797&w=2
> [2] https://github.com/lorc/xen/blob/el0_app/xen/arch/arm/domain.c#L257

Cheers,

--
Julien Grall

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