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
