From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: Elvis upstreaming plan Date: Wed, 27 Nov 2013 11:21:59 +0200 Message-ID: <20131127092159.GP959@redhat.com> References: <52955DB0.6010702@redhat.com> <20131127073501.GN959@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abel.gordon@gmail.com, anthony@codemonkey.ws, asias@redhat.com, bsd@redhat.com, digitaleric@google.com, Eran Raichstein , Jason Wang , Joel Nider , kvm@vger.kernel.org, "Michael S. Tsirkin" , pbonzini@redhat.com, Razya Ladelsky To: Abel Gordon Return-path: Received: from mx1.redhat.com ([209.132.183.28]:32548 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751980Ab3K0JWH (ORCPT ); Wed, 27 Nov 2013 04:22:07 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Nov 27, 2013 at 11:18:26AM +0200, Abel Gordon wrote: > > > Gleb Natapov wrote on 27/11/2013 09:35:01 AM: > > > On Wed, Nov 27, 2013 at 10:49:20AM +0800, Jason Wang wrote: > > > > 4. vhost statistics > > > > This patch introduces a set of statistics to monitor different > > performance > > > > metrics of vhost and our polling and I/O scheduling mechanisms. The > > > > statistics are exposed using debugfs and can be easily displayed with > a > > > > Python script (vhost_stat, based on the old kvm_stats) > > > > https://github.com/abelg/virtual_io_acceleration/commit/ > > ac14206ea56939ecc3608dc5f978b86fa322e7b0 > > > > > > How about using trace points instead? Besides statistics, it can also > > > help more in debugging. > > Definitely. kvm_stats has moved to ftrace long time ago. > > > > We should use trace points for debugging information but IMHO we should > have a dedicated (and different) mechanism to expose data that can be > easily consumed by a user-space (policy) application to control how many > vhost threads we need or any other vhost feature we may introduce > (e.g. polling). That's why we proposed something like vhost_stat > based on sysfs. > > This is not like kvm_stat that can be replaced with tracepoints. Here > we will like to expose data to "control" the system. So I would > say what we are trying to do something that resembles the ksm interface > implemented under /sys/kernel/mm/ksm/ There are control operation and there are performance/statistic gathering operations use /sys for former and ftrace for later. The fact that you need /sys interface for other things does not mean you can abuse it for statistics too. -- Gleb.