Re: [PATCH v11 3/4] softmmu/dirtylimit: implement virtual CPU throttle

[Peter Xu <peterx@redhat.com>]

On Thu, Jan 20, 2022 at 06:03:45PM +0800, Hyman Huang wrote:
> 
> 
> 在 2022/1/20 17:25, Peter Xu 写道:
> > On Thu, Jan 20, 2022 at 04:26:09PM +0800, Hyman Huang wrote:
> > > Hi，Peter. I'm working on this problem and found the reason is kind of the
> > > same as i metioned in cover letter of v10, the following is what i posted:
> > > 
> > >    2. The new implementaion of throttle algo enlightened by Peter
> > >       responds faster and consume less cpu resource than the older,
> > >       we make a impressed progress.
> > > 
> > >       And there is a viewpoint may be discussed, it is that the new
> > >       throttle logic is "passive", vcpu sleeps only after dirty ring,
> > >       is full, unlike the "auto-converge" which will kick vcpu instead
> > >       in a fixed slice time. If the vcpu is memory-write intensive
> > >       and the ring size is large, it will produce dirty memory during
> > >       the dirty ring full time and the throttle works not so good, it
> > >       means the throttle depends on the dirty ring size.
> > > 
> > >       I actually tested the new algo in two case:
> > > 
> > >       case 1: dirty-ring-size: 4096, dirtyrate: 1170MB/s
> > >       result: minimum quota dirtyrate is 25MB/s or even less
> > >               minimum vcpu util is 6%
> > > 
> > >       case 2: dirty-ring-size: 65536, dirtyrate: 1170MB/s
> > >       result: minimum quota dirtyrate is 256MB/s
> > >               minimum vcpu util is 24%
> > > 
> > >       I post this just for discussion, i think this is not a big deal
> > >       beacase if we set the dirty-ring-size to the maximum value(65536),
> > >       we assume the server's bandwidth is capable of handling it.
> > 
> > My memory is that I tested your v10 (which has this wait-at-ring-full logic)
> > already and at that time it worked well.
> > 
> > It's possible that I just got lucky with v10, so that can happen with some
> > random conditions and so far we still don't know how to hit it.
> Uh, sorry for not explaining the reason clearly. I think the reason of
> failing to throttle is "vcpu loss chance to sleep", i trace the
> kvm_dirty_ring_full event and found that when throttling a vcpu works bad,
> the kvm_dirty_ring_full event do no arise and sleep never happens
> correspondingly.

I see, that's fine.  I think I'll just try the new version when it's ready.

> 
> Two case lead to this result:
> case 1: dirty-ring-size is large and the ring full time is long, not all
> dirty ring of vcpu get full at one time, so there must be some vcpus that
> miss the chance to sleep.
> 
> case 2: guest has many vcpus, not all dirty ring of vcpu get full at one
> time. So miss the chance of sleeping too as above.

I am just not sure whether my test case matches any of above: I'm using 4096
which is the smaller ring size, meanwhile I only have 1 busy dirty thread,
iirc.

-- 
Peter Xu