linux-kernel - Re: Idea for reducing sysfs memory usage

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160217003801.GA3037@kroah.com>
Date:	Tue, 16 Feb 2016 16:38:01 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Edward Cree <ec429@...tab.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Idea for reducing sysfs memory usage

On Tue, Feb 16, 2016 at 11:46:49PM +0000, Edward Cree wrote:
> If I'm understanding correctly, when creating a sysfs dir for a kobject, we
> call populate_dir() and create a sysfs file for each of its default_attrs.
> This leads to some memory allocations, which apparently can really add up
> when, for instance, using a large number of netdevices (mostly software
> devices like VLANs and bonds whose sysfs files will probably never actually
> be used anyway).  At netdev1.1, a use case was presented for thousands -
> perhaps even hundreds of thousands - of such netdevices, at which point the
> memory overhead for all those sysfs files becomes quite significant.

Oops, missed this before.  Exactly what is that memory overhead?  Do you
have numbers?

Again, we can easily handle tens of thousands of devices today, hundred
of thousands also probably work fine, I haven't heard of anyone really
needing/wanting them except for odd benchmarks.  If you have a script I
can use to test with, I'd be glad to do so.  I'd also be interested in
the use-case for this type of thing, what is it good for?

But you are going to have to come up with some real numbers to show that
sysfs really is the issue here, and it's not something a bit higher up
the stack.

thanks,

greg k-h