Re: Elvis upstreaming plan

[Gleb Natapov <gleb@redhat.com>]

On Wed, Nov 27, 2013 at 11:33:19AM +0200, Abel Gordon wrote:
> 
> 
> Gleb Natapov <gleb@redhat.com> wrote on 27/11/2013 11:21:59 AM:
> 
> 
> > On Wed, Nov 27, 2013 at 11:18:26AM +0200, Abel Gordon wrote:
> > >
> > >
> > > Gleb Natapov <gleb@redhat.com> 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.
> 
> Agree. Any statistics that we add for debugging purposes should be
> implemented
> using tracepoints. But control and related data interfaces (that are not
> for
> debugging purposes) should be in sysfs. Look for example at
Yes things that are not for statistics only and part of control interface
that management will use should not use ftrace (I do not think adding
more knobs is a good idea, but this is for vhost maintainer to decide),
but ksm predates ftrace, so some things below could have been implemented
as ftrace points.

>  /sys/kernel/mm/ksm/full_scans
>  /sys/kernel/mm/ksm/pages_shared
>  /sys/kernel/mm/ksm/pages_sharing
>  /sys/kernel/mm/ksm/pages_to_scan
>  /sys/kernel/mm/ksm/pages_unshared
>  /sys/kernel/mm/ksm/pages_volatile
> 

--
			Gleb.