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

[Sasha Levin <levinsasha928@gmail.com>]

On Sat, 2011-06-04 at 12:17 +0200, Ingo Molnar wrote:
> * Sasha Levin <levinsasha928@gmail.com> wrote:
> 
> > On Sat, 2011-06-04 at 11:38 +0200, Ingo Molnar wrote:
> > > * Sasha Levin <levinsasha928@gmail.com> wrote:
> > > 
> > > > Coalescing MMIO allows us to avoid an exit every time we have a
> > > > MMIO write, instead - MMIO writes are coalesced in a ring which
> > > > can be flushed once an exit for a different reason is needed.
> > > > A MMIO exit is also trigged once the ring is full.
> > > > 
> > > > Coalesce all MMIO regions registered in the MMIO mapper.
> > > > Add a coalescing handler under kvm_cpu.
> > > 
> > > Does this have any effect on latency? I.e. does the guest side 
> > > guarantee that the pending queue will be flushed after a group of 
> > > updates have been done?
> > 
> > Theres nothing that detects groups of MMIO writes, but the ring size is
> > a bit less than PAGE_SIZE (half of it is overhead - rest is data) and
> > we'll exit once the ring is full.
> 
> But if the page is only filled partially and if mmio is not submitted 
> by the guest indefinitely (say it runs a lot of user-space code) then 
> the mmio remains pending in the partial-page buffer?

We flush the ring on any exit from the guest, not just MMIO exit.
But yes, from what I understand from the code - if the buffer is only
partially full and we don't take an exit, the buffer doesn't get back to
the host.

ioeventfds and such are making exits less common, so yes - it's possible
we won't have an exit in a while.

> If that's how it works then i *really* don't like this, this looks 
> like a seriously mis-designed batching feature which might have 
> improved a few server benchmarks but which will introduce random, 
> hard to debug delays all around the place!


-- 

Sasha.