On 21.06.2017 12:37, Paolo Bonzini wrote: > > > 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? Only when we add that option as a new feature. >> 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. OK, so that sounds like we're in agreement that this is a useful feature. The question is whether to do it via an interactive command or a command line switch, or both. I guess my vote would be to do both, i.e. add '--debugfs-include-past' as a new command line switch to the patch, but leave 't' in place. Thoughts? Ciao, Stefan
