lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 28 May 2020 07:22:25 +0200 From: Paolo Bonzini <pbonzini@...hat.com> To: David Ahern <dsahern@...il.com>, Jakub Kicinski <kuba@...nel.org>, Emanuele Giuseppe Esposito <eesposit@...hat.com> Cc: kvm@...r.kernel.org, Christian Borntraeger <borntraeger@...ibm.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, Andrew Lunn <andrew@...n.ch> Subject: Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics On 28/05/20 00:21, David Ahern wrote: > On 5/27/20 3:07 PM, Paolo Bonzini wrote: >> I see what you meant now. statsfs can also be used to enumerate objects >> if one is so inclined (with the prototype in patch 7, for example, each >> network interface becomes a directory). > > there are many use cases that have 100's to 1000's have network devices. > Having a sysfs entry per device already bloats memory usage for these > use cases; another filesystem with an entry per device makes that worse. > Really the wrong direction for large scale systems. Hi David, IMO the important part for now is having a flexible kernel API for exposing statistics across multiple subsystems, so that they can be harvested in an efficient way. The userspace API is secondary, and multiple APIs can be added to cater for different usecases. For example, as of the first five patches the memory usage is the same as what is now in the mainline kernel, since all the patchset does is take existing debugfs inodes and move them to statsfs. I agree that, if the concept is extended to the whole kernel, scalability and memory usage becomes an issue; and indeed, the long-term plan is to support a binary format that is actually _more_ efficient than the status quo for large scale systems. In the meanwhile, the new filesystem can be disabled (see the difference between "STATS_FS" and "STATS_FS_API") if it imposes undesirable overhead. Thanks, Paolo
Powered by blists - more mailing lists