[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b6fa4439-c6b8-63a4-84fd-fbac3d4f10fd@gmail.com>
Date: Wed, 27 May 2020 16:21:55 -0600
From: David Ahern <dsahern@...il.com>
To: Paolo Bonzini <pbonzini@...hat.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 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.
Powered by blists - more mailing lists