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.
