Thread (15 messages) flat view 15 messages, 7 authors, 2020-06-04

Re: [PATCH v2 0/5] Statsfs: a new ram-based file sytem for Linux kernel statistics

From: David Rientjes <rientjes@google.com>
Date: 2020-05-05 17:07:42
Also in: kvm, linux-fsdevel, linux-mips, linux-s390, lkml

On Tue, 5 May 2020, Paolo Bonzini wrote:
quoted
quoted
quoted
Since this is becoming a generic API (good!!), maybe we can discuss
possible ways to optimize gathering of stats in mass?
Sure, the idea of a binary format was considered from the beginning in
[1], and it can be done either together with the current filesystem, or
as a replacement via different mount options.
ASCII stats are not scalable. A binary format is definitely the way to go.
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?
ASCII stats are necessary for quick userspace consumption and for
backwards compatibility with KVM debugfs (which is not an ABI, but it's
damn useful and should not be dropped without providing something as
handy), so this is what this series starts from.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help