From: Julien Grall <julien.grall@arm.com>
To: George Dunlap <george.dunlap@citrix.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Dario Faggioli <dario.faggioli@citrix.com>
Cc: Volodymyr Babchuk <vlad.babchuk@gmail.com>,
Artem Mygaiev <joculator@gmail.com>,
Andrii Anisov <andrii_anisov@epam.com>,
Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [ARM] Native application design and discussion (I hope)
Date: Wed, 10 May 2017 11:48:28 +0100 [thread overview]
Message-ID: <64eede57-85be-99f4-cbd8-5d28a430980b@arm.com> (raw)
In-Reply-To: <c0307ee7-44e5-1ebc-b8e1-785455ecbc4e@citrix.com>
Hi George,
On 05/10/2017 11:03 AM, George Dunlap wrote:
> On 10/05/17 11:00, Julien Grall wrote:
>>
>>
>> On 05/10/2017 10:56 AM, George Dunlap wrote:
>>> On 09/05/17 19:29, Stefano Stabellini wrote:
>>>> On Tue, 9 May 2017, Dario Faggioli wrote:
>>>>>>> And it should not be hard to give such code access to the context
>>>>>>> of
>>>>>>> the vCPU that was previously running (in x86, given we implement
>>>>>>> what
>>>>>>> we call lazy context switch, it's most likely still loaded in the
>>>>>>> pCPU!).
>>>>>>
>>>>>> I agree with Stefano, switching to the idle vCPU is a pretty bad
>>>>>> idea.
>>>>>>
>>>>>> the idle vCPU is a fake vCPU on ARM to stick with the common code
>>>>>> (we
>>>>>> never leave the hypervisor). In the case of the EL0 app, we want to
>>>>>> change exception level to run the code with lower privilege.
>>>>>>
>>>>>> Also IHMO, it should only be used when there are nothing to run and
>>>>>> not
>>>>>> re-purposed for running EL0 app.
>>>>>>
>>>>> It's already purposed for running when there is nothing to do _or_ when
>>>>> there are tasklets.
>>>>>
>>>>> I do see your point about privilege level, though. And I agree with
>>>>> George that it looks very similar to when, in the x86 world, we tried
>>>>> to put the infra together for switching to Ring3 to run some pieces of
>>>>> Xen code.
>>>>
>>>> Right, and just to add to it, context switching to the idle vcpu has a
>>>> cost, but it doesn't give us any security benefits whatsever. If Xen is
>>>> going to spend time on context switching, it is better to do it in a
>>>> way that introduces a security boundary.
>>>
>>> "Context switching" to the idle vcpu doesn't actually save or change any
>>> registers, nor does it flush the TLB. It's more or less just accounting
>>> for the scheduler. So it has a cost (going through the scheduler) but
>>> not a very large one.
>>
>> It depends on the architecture. For ARM we don't yet support lazy
>> context switch. So effectively, the cost to "context switch" to the idle
>> vCPU will be quite high.
>
> Oh, right. Sorry, I thought I had seen code implementing lazy context
> switch in ARM, but I must have imagined it. That is indeed a material
> consideration.
>
> Is there a particular reason that lazy context switch is difficult on
> ARM? If not it should be a fairly important bit of low-hanging fruit
> from a performance perspective.
I am not entirely sure what you are doing on x86. Let me explain what we
do and why context switch is heavy on ARM.
In the case of ARM, when entering to the hypervisor, we only save the
bare minimum (all non-banked registers + registers useful for handling
guest request), and left the rest untouched.
Our save/restore functions are quite big because it involving
saving/restore state of the interrupt controller, FPU... So we have a
fast exit/entry but slow context switch.
What we currently do is avoiding save/restore the idle vCPU because we
always stay in the hypervisor exception level. However we still restore
all the registers of the previous running vCPU and restore the one of
the next running vCPU.
This has a big impact on the workload when running vCPU and waiting for
interrupts (hence the patch from Stefano to limit entering in the
hypervisor though it is not by default).
I made the assumption the idle vCPU is only running when nothing has to
be done. But as you mentioned tasklet can be done there too. So running
tasklet on Xen ARM will have an high cost.
A list of optimization we could do on ARM is:
- Avoiding restore if the vCPU stay the same before and after idle vPCU
- Avoiding save/restore if vCPU is dedicated to a pCPU
Do you have any other optimization on x86?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-05-10 10:48 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-06 20:21 [ARM] Native application design and discussion (I hope) Volodymyr Babchuk
2017-04-06 21:31 ` Stefano Stabellini
2017-04-07 11:03 ` Volodymyr Babchuk
2017-04-07 23:36 ` Stefano Stabellini
2017-04-11 20:32 ` Stefano Stabellini
2017-04-12 18:13 ` Dario Faggioli
2017-04-12 19:17 ` Stefano Stabellini
2017-04-20 20:20 ` Volodymyr Babchuk
2017-04-21 14:42 ` Andrii Anisov
2017-04-21 15:49 ` Julien Grall
2017-04-21 16:08 ` Volodymyr Babchuk
2017-04-21 16:20 ` Andrii Anisov
2017-04-21 20:58 ` Stefano Stabellini
2017-04-21 21:17 ` Stefano Stabellini
2017-04-24 16:56 ` Andrii Anisov
2017-04-24 18:08 ` Stefano Stabellini
2017-04-25 10:15 ` Andrii Anisov
2017-05-05 10:51 ` Andrii Anisov
2017-05-05 19:28 ` Stefano Stabellini
2017-05-08 10:46 ` George Dunlap
2017-05-08 18:31 ` Stefano Stabellini
2017-05-08 18:33 ` Julien Grall
2017-05-09 8:53 ` George Dunlap
2017-05-10 16:38 ` Andrii Anisov
2017-05-09 10:13 ` Dario Faggioli
2017-05-09 10:32 ` Julien Grall
2017-05-09 11:08 ` Dario Faggioli
2017-05-09 11:19 ` Julien Grall
2017-05-09 18:29 ` Stefano Stabellini
2017-05-10 9:56 ` George Dunlap
2017-05-10 10:00 ` Julien Grall
2017-05-10 10:03 ` George Dunlap
2017-05-10 10:48 ` Julien Grall [this message]
2017-05-10 17:37 ` Volodymyr Babchuk
2017-05-10 18:05 ` Stefano Stabellini
2017-05-10 19:04 ` Julien Grall
2017-05-11 10:07 ` Julien Grall
2017-05-11 11:28 ` Volodymyr Babchuk
2017-05-10 18:08 ` Andrii Anisov
2017-05-10 18:24 ` Stefano Stabellini
2017-05-11 15:19 ` Volodymyr Babchuk
2017-05-11 15:35 ` Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope)) Julien Grall
2017-05-11 16:35 ` George Dunlap
2017-05-11 17:14 ` Volodymyr Babchuk
2017-05-11 17:20 ` George Dunlap
2017-05-11 17:53 ` Lars Kurth
2017-05-11 17:14 ` George Dunlap
2017-05-11 17:16 ` George Dunlap
2017-05-11 18:13 ` Volodymyr Babchuk
2017-05-12 11:48 ` George Dunlap
2017-05-12 18:43 ` Stefano Stabellini
2017-05-12 19:04 ` Volodymyr Babchuk
2017-05-15 11:21 ` George Dunlap
2017-05-15 17:32 ` Stefano Stabellini
2017-05-11 18:04 ` Stefano Stabellini
2017-05-11 18:39 ` Volodymyr Babchuk
2017-05-05 11:09 ` [ARM] Native application design and discussion (I hope) Andrii Anisov
2017-04-24 19:11 ` Julien Grall
2017-04-24 21:41 ` Volodymyr Babchuk
2017-04-25 11:43 ` Julien Grall
2017-04-26 21:44 ` Volodymyr Babchuk
2017-04-27 17:26 ` Volodymyr Babchuk
2017-05-02 12:52 ` Julien Grall
2017-05-02 12:42 ` Julien Grall
2017-04-25 8:52 ` Andrii Anisov
2017-04-21 15:57 ` Julien Grall
2017-04-21 16:16 ` Volodymyr Babchuk
2017-04-21 16:47 ` Julien Grall
2017-04-21 17:04 ` Volodymyr Babchuk
2017-04-21 17:38 ` Julien Grall
2017-04-21 18:35 ` Volodymyr Babchuk
2017-04-24 11:00 ` Julien Grall
2017-04-24 21:29 ` Volodymyr Babchuk
2017-04-21 21:24 ` Stefano Stabellini
2017-04-24 16:14 ` Andrii Anisov
2017-04-24 16:46 ` Andrii Anisov
2017-04-27 15:25 ` George Dunlap
2017-05-02 12:45 ` Julien Grall
2017-05-12 18:47 Volodymyr Babchuk
2017-05-15 12:51 ` George Dunlap
2017-05-15 17:35 ` Stefano Stabellini
2017-05-15 13:54 ` Andrii Anisov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64eede57-85be-99f4-cbd8-5d28a430980b@arm.com \
--to=julien.grall@arm.com \
--cc=andrii_anisov@epam.com \
--cc=dario.faggioli@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=joculator@gmail.com \
--cc=sstabellini@kernel.org \
--cc=vlad.babchuk@gmail.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.