From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Raspl Subject: Re: [PATCH v1 16/19] tools/kvm_stat: add new interactive command 't' Date: Wed, 21 Jun 2017 08:54:49 +0200 Message-ID: References: <20170607190843.76869-1-raspl@linux.vnet.ibm.com> <20170607190843.76869-17-raspl@linux.vnet.ibm.com> <535a16ce-8f48-8446-5e4a-4d7e375086bd@redhat.com> <3ec6c83a-5554-2497-ed58-b6da6d3c6868@linux.vnet.ibm.com> <828a0b8f-f5d0-b11a-c2ef-b3b3f2c91e8c@redhat.com> <1803ed91-0d78-742f-66a7-a88dd4dc5786@linux.vnet.ibm.com> <9b5eb94a-94f5-817a-c371-8beb12f613f3@redhat.com> <19a20f2b-f143-a14e-e4da-090aa55705e3@linux.vnet.ibm.com> Reply-To: raspl@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: rkrcmar@redhat.com, frankja@linux.vnet.ibm.com To: Paolo Bonzini , kvm@vger.kernel.org Return-path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:53829 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751742AbdFUGyz (ORCPT ); Wed, 21 Jun 2017 02:54:55 -0400 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v5L6s06B079412 for ; Wed, 21 Jun 2017 02:54:54 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0b-001b2d01.pphosted.com with ESMTP id 2b76d0x1fb-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Jun 2017 02:54:54 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 21 Jun 2017 07:54:52 +0100 In-Reply-To: Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: On 20.06.2017 16:47, Paolo Bonzini wrote: > > > On 20/06/2017 16:17, 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. 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. Ciao, Stefan