[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [ARM] Native application design and discussion (I hope)
Hi Andrii, On 24/04/2017 17:56, Andrii Anisov wrote: On 21.04.17 23:58, Stefano Stabellini wrote:On Fri, 21 Apr 2017, Andrii Anisov wrote: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 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. - FPU is taking time to save/restore, you could make it lazy- It might be possible to limit the number of LRs saved/restored depending on the number of LRs used by a domain. - ...If the numbers are still bad, then we can start stripping some part (for instance you may not need FPU). Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |