Re: [PATCH v17 6/8] softmmu/dirtylimit: Implement virtual CPU throttle

[Peter Xu]

On Wed, May 25, 2022 at 11:38:26PM +0800, Hyman Huang wrote:
> > 2. Also this algorithm only control or limits dirty rate by guest
> > writes. There can be some memory dirtying done by virtio based devices
> > which is accounted only at qemu level so may not be accounted through
> > dirty rings so do we have plan for that in future? Those are not issue
> > for auto-converge as it slows full VM but dirty rate limit only slows
> > guest writes.
> > 
> From the migration point of view, time spent on migrating memory is far
> greater than migrating devices emulated by qemu. I think we can do that when
> migrating device costs the same magnitude time as migrating memory.
> 
> As to auto-converge, it throttle vcpu by kicking it and force it to sleep
> periodically. The two seems has no much difference from the perspective of
> internal method but the auto-converge is kind of "offensive" when doing
> restraint. I'll read the auto-converge implementation code and figure out
> the problem you point out.

This seems to be not virtio-specific, but can be applied to any device DMA
writting to guest mem (if not including vfio).  But indeed virtio can be
normally faster.

I'm also curious how fast a device DMA could dirty memories.  This could be
a question to answer to all vcpu-based throttling approaches (including the
quota based approach that was proposed on KVM list).  Maybe for kernel
virtio drivers we can have some easier estimation?  My guess is it'll be
much harder for DPDK-in-guest (aka userspace drivers) because IIUC that
could use a large chunk of guest mem.

[copy Jason too]

-- 
Peter Xu