On 04.06.2011, at 13:27, Ingo Molnar wrote: > > * Alexander Graf <agraf@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
