Linux-Fsdevel Archive on lore.kernel.org help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch> To: Emanuele Giuseppe Esposito <eesposit@redhat.com> Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org, linux-doc@vger.kernel.org, netdev@vger.kernel.org, Emanuele Giuseppe Esposito <e.emanuelegiuseppe@gmail.com>, linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org, Jonathan Adams <jwadams@google.com>, Christian Borntraeger <borntraeger@de.ibm.com>, Alexander Viro <viro@zeniv.linux.org.uk>, David Rientjes <rientjes@google.com>, linux-fsdevel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, Jim Mattson <jmattson@google.com> Subject: Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics Date: Wed, 27 May 2020 23:17:27 +0200 [thread overview] Message-ID: <20200527211727.GB818296@lunn.ch> (raw) In-Reply-To: <20200526110318.69006-1-eesposit@redhat.com> On Tue, May 26, 2020 at 01:03:10PM +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]. > > Statsfs offers a generic and stable API, allowing any kind of > directory/file organization and supporting multiple kind of aggregations > (not only sum, but also average, max, min and count_zero) and data types > (boolean, unsigned/signed and custom types). The implementation, which is > a generalization of KVM’s debugfs statistics code, takes care of gathering > and displaying information at run time; users only need to specify the > values to be included in each source. > > Statsfs would also be a different mountpoint from debugfs, and would not > suffer from limited access due to the security lock down patches. Its main > function is to display each statistics as a file in the desired folder > hierarchy defined through the API. Statsfs files can be read, and possibly > cleared if their file mode allows it. > > Statsfs has two main components: the public API defined by > include/linux/statsfs.h, and the virtual file system which should end up in > /sys/kernel/stats. > Hi Emanuele > The API has two main elements, values and sources. Kernel subsystems like > KVM can use the API to create a source, add child sources/values/aggregates > and register it to the root source (that on the virtual fs would be > /sys/kernel/statsfs). Another issue i see with networking is that statistic counters can be dynamic. They can come and go. One of the drivers i work on has extra statistics available when a fibre interface is used, compared to a copper interface. And this happens at run time. The netlink API has no problems with this. It is a snapshot of what counters are currently available. There is no state in the API. In my humble opinion, networking is unlikely to adopt your approach. You probably want to look around for other subsystems which have statistics, and see if you can cover their requirements, and get them on board. Andrew
prev parent reply other threads:[~2020-05-27 21:17 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-26 11:03 [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics Emanuele Giuseppe Esposito 2020-05-26 11:03 ` [PATCH v3 1/7] stats_fs API: create, add and remove stats_fs sources and values Emanuele Giuseppe Esposito 2020-05-26 11:03 ` [PATCH v3 2/7] documentation for stats_fs Emanuele Giuseppe Esposito 2020-06-04 0:23 ` Randy Dunlap 2020-06-04 15:34 ` Emanuele Giuseppe Esposito 2020-05-26 11:03 ` [PATCH v3 3/7] kunit: tests for stats_fs API Emanuele Giuseppe Esposito 2020-05-27 10:05 ` Alan Maguire 2020-05-27 13:26 ` Emanuele Giuseppe Esposito 2020-05-26 11:03 ` [PATCH v3 4/7] stats_fs fs: virtual fs to show stats to the end-user Emanuele Giuseppe Esposito 2020-05-26 11:03 ` [PATCH v3 5/7] kvm_main: replace debugfs with stats_fs Emanuele Giuseppe Esposito 2020-05-26 11:03 ` [PATCH v3 6/7] [not for merge] kvm: example of stats_fs_value show function Emanuele Giuseppe Esposito 2020-05-26 11:03 ` [PATCH v3 7/7] [not for merge] netstats: example use of stats_fs API Emanuele Giuseppe Esposito 2020-05-26 14:16 ` Andrew Lunn 2020-05-26 15:45 ` Emanuele Giuseppe Esposito 2020-05-26 22:31 ` [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics Jakub Kicinski 2020-05-27 13:14 ` Emanuele Giuseppe Esposito 2020-05-27 13:33 ` Andrew Lunn 2020-05-27 15:00 ` Paolo Bonzini 2020-05-27 20:23 ` Jakub Kicinski 2020-05-27 21:07 ` Paolo Bonzini 2020-05-27 21:27 ` Jakub Kicinski 2020-05-27 21:44 ` Paolo Bonzini 2020-05-27 22:21 ` David Ahern 2020-05-28 5:22 ` Paolo Bonzini 2020-05-27 21:17 ` Andrew Lunn [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200527211727.GB818296@lunn.ch \ --to=andrew@lunn.ch \ --cc=borntraeger@de.ibm.com \ --cc=e.emanuelegiuseppe@gmail.com \ --cc=eesposit@redhat.com \ --cc=jmattson@google.com \ --cc=jwadams@google.com \ --cc=kvm-ppc@vger.kernel.org \ --cc=kvm@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mips@vger.kernel.org \ --cc=linux-s390@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=netdev@vger.kernel.org \ --cc=pbonzini@redhat.com \ --cc=rientjes@google.com \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).