On 21/06/2017 08:54, Stefan Raspl wrote: >>>> Maybe kvm_stat could take an option for "do not reset debugfs on >>>> startup"? Is there a case where kvm_stat would be invoked for a while >>>> and _then_ you press 't'? >>> Maybe when one watches the output for a while and wonders whether >>> the current (strange) distribution of events has been like that ever >>> since? >> That would probably be served better by firing _another_ separate >> kvm_stat and comparing the two, since there's no reset option. > Yeah, but that will only work from point X onwards. If you just > happen to realize at point X that things look a bit strange and only > then realize that the "historic" data might be of interest for > comparison, then 't' is your friend. But wouldn't historic data always available from a fresh invocation of kvm_stat (with a --debugfs-include-past or similar) option? > The thing is that debugfs was actually reporting "historic" data > exclusively up to the point where > 9f114a03c6854f49065dd036c17e1b4bb947f842 was committed. In that > patch, as a side effect I changed things so that both, debugfs and > tracepoints, would consistently report number of events from > kvm_stat startup onwards, which made a hell of a lot more sense to > me especially when starting kvmstat with '-td'. Still, the previous > behavior of debugfs probably had its merits, so this patch is an > attempt to get the best of both worlds. I understand, and I agree. I'm just not sure that the interactive command is the best way to achieve it. Paolo
