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: <20160217004730.GA7558@kroah.com>
Date:	Tue, 16 Feb 2016 16:47:30 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Edward Cree <ec429@...tab.net>
Cc:	linux-kernel@...r.kernel.org, David Ahern <dsa@...ulusnetworks.com>
Subject: Re: Idea for reducing sysfs memory usage

On Wed, Feb 17, 2016 at 12:37:38AM +0000, Edward Cree wrote:
> On 16/02/16 23:55, Greg Kroah-Hartman wrote:
> >On Tue, Feb 16, 2016 at 11:46:49PM +0000, Edward Cree wrote:
> >>Sorry if this has been suggested before, but if so I couldn't find it.
> >>Short version: could a sysfs dir reference a list of default attributes
> >>rather than having to instantiate them all?
> >Shorter version, why do you think it is?  :)
> >
> >Have you done some testing of the amount of memory that sysfs entries
> >consume and found any problems with it?
> Two reasons:
> a) in his netdev1.1 talk "Scaling the Number of Network Interfaces on
> Linux",
>    David Ahern claimed a memory overhead of (iirc) about 45kB per netdevice,
>    of which he attributed (again, iirc) about 20kB to sysfs entries.  He
> also
>    indicated that this was a problem for his use case.  (My apologies to
>    David if I've misrepresented him.  CCed him so he can correct me.)

How many sysfs entries are you creating for that 20kb?  And how did you
measure it?  If you don't access the files, the backing store is not
allocated, saving you a lot of memory.  If you do access it, it will be
freed later on afterward, so it's sometimes really hard to measure this
accurately.

> b) my reading of the code suggested it was allocating stuff for every call
> to
>    sysfs_create_file() in the loop in populate_dir().
> Having re-read __kernfs_new_node() and struct kernfs_node, I now realise I
> misinterpreted them - the name isn't being allocated at all
> (kstrdup_const())
> and the struct kernfs_node consists chiefly (if not entirely) of fields
> specific to the individual file rather than shareable between multiple
> instances.  So there isn't any memory we can save here.

That's good to verify that we have already solved this, thanks :)

> Sorry for the noise.

Not a problem.

greg k-h