[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [ARM] Native application design and discussion (I hope)
Julien, >>>> 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 > 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? You can take a look at my context switch routines at [2]. [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 -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babchuk@xxxxxxxxx _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |