From: Paolo Bonzini <pbonzini@redhat.com>
To: David Rientjes <rientjes@google.com>
Cc: Jim Mattson <jmattson@google.com>,
Emanuele Giuseppe Esposito <eesposit@redhat.com>,
Jonathan Adams <jwadams@google.com>,
kvm list <kvm@vger.kernel.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
David Hildenbrand <david@redhat.com>,
Cornelia Huck <cohuck@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Emanuele Giuseppe Esposito <e.emanuelegiuseppe@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-mips@vger.kernel.org, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
Linux FS Devel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v2 0/5] Statsfs: a new ram-based file sytem for Linux kernel statistics
Date: Tue, 5 May 2020 19:21:54 +0200 [thread overview]
Message-ID: <6cfdf81f-caef-2489-0906-25915d9d58ff@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2005051003380.216575@chino.kir.corp.google.com>
On 05/05/20 19:07, David Rientjes wrote:
>> I am totally in favor of having a binary format, but it should be
>> introduced as a separate series on top of this one---and preferably by
>> someone who has already put some thought into the problem (which
>> Emanuele and I have not, beyond ensuring that the statsfs concept and
>> API is flexible enough).
>>
> The concern is that once this series is merged then /sys/kernel/stats
> could be considered an ABI and there would be a reasonable expectation
> that it will remain stable, in so far as the stats that userspace is
> interested in are stable and not obsoleted.
>
> So is this a suggestion that the binary format becomes complementary to
> statsfs and provide a means for getting all stats from a single subsystem,
> or that this series gets converted to such a format before it is merged?
The binary format should be complementary. The ASCII format should
indeed be considered stable even though individual statistics would come
and go. It may make sense to allow disabling ASCII files via mount
and/or Kconfig options; but either way, the binary format can and should
be added on top.
I have not put any thought into what the binary format would look like
and what its features would be. For example these are but the first
questions that come to mind:
* would it be possible to read/clear an arbitrary statistic with
pread/pwrite, or do you have to read all of them?
* if userspace wants to read the schema just once and then read the
statistics many times, how is it informed of schema changes?
* and of course the details of how the schema (names of stat and
subsources) is encoded and what details it should include about the
values (e.g. type or just signedness).
Another possibility is to query stats via BPF. This could be a third
way to access the stats, or it could be alternative to a binary format.
Paolo
next prev parent reply other threads:[~2020-05-05 17:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-04 11:03 [PATCH v2 0/5] Statsfs: a new ram-based file sytem for Linux kernel statistics Emanuele Giuseppe Esposito
2020-05-04 11:03 ` [PATCH v2 1/5] refcount, kref: add dec-and-test wrappers for rw_semaphores Emanuele Giuseppe Esposito
2020-05-04 11:03 ` [PATCH v2 2/5] stats_fs API: create, add and remove stats_fs sources and values Emanuele Giuseppe Esposito
2020-05-04 22:11 ` Randy Dunlap
2020-05-04 11:03 ` [PATCH v2 3/5] kunit: tests for stats_fs API Emanuele Giuseppe Esposito
2020-05-04 11:03 ` [PATCH v2 4/5] stats_fs fs: virtual fs to show stats to the end-user Emanuele Giuseppe Esposito
2020-05-04 11:03 ` [PATCH v2 5/5] kvm_main: replace debugfs with stats_fs Emanuele Giuseppe Esposito
2020-05-04 21:37 ` [PATCH v2 0/5] Statsfs: a new ram-based file sytem for Linux kernel statistics David Rientjes
2020-05-05 9:18 ` Emanuele Giuseppe Esposito
2020-05-05 16:53 ` Jim Mattson
2020-05-05 17:02 ` Paolo Bonzini
2020-05-05 17:07 ` David Rientjes
2020-05-05 17:21 ` Paolo Bonzini [this message]
2020-05-05 17:30 ` Christian Borntraeger
2020-06-04 11:59 ` Amit Kucheria
2020-05-07 17:45 ` Jonathan Adams
2020-05-08 9:44 ` Paolo Bonzini
2020-05-11 9:37 ` Emanuele Giuseppe Esposito
2020-05-11 17:02 ` Jonathan Adams
2020-05-11 17:34 ` Paolo Bonzini
2020-05-14 17:35 ` Jonathan Adams
2020-05-14 17:42 ` Paolo Bonzini
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=6cfdf81f-caef-2489-0906-25915d9d58ff@redhat.com \
--to=pbonzini@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.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-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=rientjes@google.com \
--cc=viro@zeniv.linux.org.uk \
--cc=vkuznets@redhat.com \
/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: link
Be 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).