Re: [PATCH] kvm tools: Add MMIO coalescing support

Alexander Graf
2011-06-04T11:53:52Z

On 04.06.2011, at 13:27, Ingo Molnar wrote:

>
> * Alexander Graf <agraf@suse.de> wrote:
>
>>> So? I only inquired about latencies, asking what impact on
>>> latencies is. Regardless of the circumstances we do not want to
>>> introduce unbound latencies.
>>>
>>> If there are no unbound latencies then i'm happy.
>>
>> Sure, I'm just saying that the mechanism was invented for
>> unmodified guests :).
>
> Well, but that does not excuse the introduction of unbound latencies.
> (if those latencies are introduced here - i don't know, i'm asking.)
>
>>> Well, since user-space gets the MMIOs only once the guest exits
>>> it's not independent, is it?
>>
>> If we don't know when a guest ends an MMIO stream, we can't
>> optimize it. Period. [...]
>
> But that's no excuse. If you cannot optimize them without
> unnacceptable collateral damage then don't optimize it then.
>
> That's why i asked what the damage is - if there's any damage.

Ok, reading through the source on what coalesced mmio actually does, it seems fairly simple.

1) the kvm user space user registers a coalesced MMIO region on registers that are not latency crucial
2) when the guest writes an MMIO, it gets written to a shared page
3) every time kvm exits its ioctl to user space, the coalesced ring gets analyzed for new data and MMIOs get fired

So the simple rule is: don't register a coalesced MMIO region for a region where latency matters. However, it's great for NVRAM and others where you don't care whether a write actually happens in that moment, as there's no trigger behind it. It might also make sense for selector registers which are meaningless until you ring the doorbell.

Alex