On Fri, Jul 15, 2022 at 05:07:45PM +0000, Sean Christopherson wrote: > On Fri, Jul 15, 2022, Peter Xu wrote: > > On Fri, Jul 15, 2022 at 04:23:54PM +0000, Sean Christopherson wrote: > > > And the reasoning behind not having kvm_run.dirty_count is that it's fully > > > redundant if KVM provides a stat, and IMO such a stat will be quite helpful for > > > things beyond dirty quotas, e.g. being able to see which vCPUs are dirtying memory > > > from the command line for debug purposes. > > > > Not if with overflow in mind? Note that I totally agree the overflow may > > not even happen, but I think it makes sense to consider as a complete > > design of ceiling-based approach. Think the Millennium bug, we never know > > what will happen in the future.. > > > > So no objection too on having stats for dirty pages, it's just that if we > > still want to cover the overflow issue we'd make dirty_count writable, then > > it'd still better be in kvm_run, imho. > > Yeah, never say never, but unless my math is wrong, overflow isn't happening anytime > soon. And if future CPUs can overflow the number of dirty pages, then they'll be > able to overflow a number of stats, at which point I think we'll want a generic > ioctl() to reset _all_ stats. It's slightly different as this affects functionality, unlike most stats. I'll leave that to Shivam to see his preference. If to go that way, I hope we can at least have some WARN_ON_ONCE() on detecting overflows of "count". Thanks, -- Peter Xu
