On 13/02/13 16:25, Christoffer Dall wrote:
> On Wed, Feb 13, 2013 at 11:21 AM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
>> On 13/02/13 16:07, Christoffer Dall wrote:
>>> On Wed, Feb 13, 2013 at 10:46 AM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
>>>> At the moment, KVM/ARM is quite heavy handed when it comes to i-cache
>>>> invalidation, as it is flushed on each stage-2 mapping.
>>>>
>>>> An alternative is to mark each page as non-executable (courtesy of the
>>>> XN flag), and then to invalidate the i-cache when the CPU tries to
>>>> execute a page.
>>>>
>>>> We're basically trading off invalidation for faults. Performance wise,
>>>> the performance difference is very modest (I've seen a 0.2%
>>>> improvement over 10 runs of "hackbench 100 process 1000"). But the
>>>> important thing in my opinion is that it reduces the impact of the VM
>>>> on the whole system (fault handling only impact the VM while
>>>> invalidation is global).
>>>>
>>>> Code wise, this introduce a bit of restructuring in our stage-2
>>>> manipulation code, making the code a bit cleaner (IMHO). Note that
>>>> these patches are against my arm64 branch, and won't apply on anything
>>>> else.
>>>>
>>>> As always, comments welcome.
>>>>
>>>
>>> Hey Marc,
>>>
>>> I'll give this a once-over. From my initial glance there are some
>>> issues with the stage2_get_pte stuff if you think about section
>>> mappings later on, and while I kind of see the background, I'm not
>>> sure it's as bad as it's made out to be.
>>
>> We certainly need to cater for section mapping, and that would probably
>> deserve a stage2_{get_pmd,set_pmd_at}.
>>
>> My problem with the single stage2_set_pte function is that it makes it
>> very hard to perform a read-modify-write operation on an existing PTE.
>> We don't really need it now, as we only ever change one single bit (RW).
>> But as soon as you need a second bit (XN, for example), you're screwed.
>> The pathological example being a page that has both code and data that
>> needs to be written.
>>
>
> it's definitely on the heavy side. I'll give it a more careful review.
>
>>> In any case, we really need to measure the impact of this on both a
>>> wider range of workloads inside the VM and on the host performance.
>>
>> Agreed. I plan to do that at one point once I get all my pending patches
>> properly aligned (a bit busy with BE guests at the moment).
>>
> BE as in Big Endian? How come that's a priority? (just curious)
Not exactly a priority, just that there's a sudden burst of BE activity
on LAKML, due to Ben Dooks having posted a number of BE8 support
patches. Of course, I had to try that, and found out that our MMIO
handling is fairly broken when it comes to endianness.
I've fixed that (at least for BE guests, I'm not really considering BE
host - yet). But now virtio goes tits up. More patches.
> As per the measurements, let's sync, I may be doing something similar.
Sure. it's unlikely to happen in the next couple of weeks anyway...
> I use this horrible set of scripts to measure performance stuff, they
> may be useful to you too: https://github.com/chazy/kvmperf
Interesting. Thanks for the pointer.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
