[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200526153128.448bfb43@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date: Tue, 26 May 2020 15:31:28 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Emanuele Giuseppe Esposito <eesposit@...hat.com>
Cc: kvm@...r.kernel.org,
Christian Borntraeger <borntraeger@...ibm.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Jim Mattson <jmattson@...gle.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Emanuele Giuseppe Esposito <e.emanuelegiuseppe@...il.com>,
David Rientjes <rientjes@...gle.com>,
Jonathan Adams <jwadams@...gle.com>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mips@...r.kernel.org, kvm-ppc@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux
kernel statistics
On Tue, 26 May 2020 13:03:10 +0200 Emanuele Giuseppe Esposito wrote:
> There is currently no common way for Linux kernel subsystems to expose
> statistics to userspace shared throughout the Linux kernel; subsystems have
> to take care of gathering and displaying statistics by themselves, for
> example in the form of files in debugfs. For example KVM has its own code
> section that takes care of this in virt/kvm/kvm_main.c, where it sets up
> debugfs handlers for displaying values and aggregating them from various
> subfolders to obtain information about the system state (i.e. displaying
> the total number of exits, calculated by summing all exits of all cpus of
> all running virtual machines).
>
> Allowing each section of the kernel to do so has two disadvantages. First,
> it will introduce redundant code. Second, debugfs is anyway not the right
> place for statistics (for example it is affected by lockdown)
>
> In this patch series I introduce statsfs, a synthetic ram-based virtual
> filesystem that takes care of gathering and displaying statistics for the
> Linux kernel subsystems.
>
> The file system is mounted on /sys/kernel/stats and would be already used
> by kvm. Statsfs was initially introduced by Paolo Bonzini [1].
What's the direct motivation for this work? Moving KVM stats out of
debugfs?
In my experience stats belong in the API used for creating/enumerating
objects, statsfs sounds like going in the exact opposite direction -
creating a parallel structure / hierarchy for exposing stats. I know
nothing about KVM but are you sure all the info that has to be exposed
will be stats?
In case of networking we have the basic stats in sysfs, under the
netdevice's kobject. But since we're not using sysfs much any more
for config, new stats are added in netlink APIs. Again - same APIs
used for enumeration and config.
Powered by blists - more mailing lists