[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <56C3B4E9.7030207@cantab.net>
Date: Tue, 16 Feb 2016 23:46:49 +0000
From: Edward Cree <ec429@...tab.net>
To: linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Idea for reducing sysfs memory usage
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?
Long version:
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.
Thus I was wondering if it would be feasible to replace the instantiation of
these default attributes with, in principle, a pointer to the default_attr
list, which already contains the methods needed to show or store the
attribute, and need not be duplicated for each sysfs dir referring to it.
In practice it would probably make sense to build a fast-lookup data
structure from the list when the latter is first created, since the list is
(as I understand it) never changed.
Then for instance, a lookup on the directory would search both the default
attrs list and the rbtree of runtime-added nodes. I don't think it would
ever be necessary for runtime code to _remove_ a default attribute from a
dir, but if it were, then perhaps a negative entry could be added to the
rbtree, and that tree could always be searched first - then, if the negative
entry was found, the search of the default list would be skipped.
Of course, all the other operations on the directory would similarly have to
be modified to take account of there being two places in which an attribute
could be defined, but I believe (perhaps naïvely) that this would not be
excessively painful.
This could potentially save memory whenever large numbers of directories of
the same 'type' are created in sysfs; not just netdevices, but also for
instance PCI devices and their 'power' subdirectories. While it would
slightly slow down sysfs accesses, I can't quite imagine a situation in
which the speed of sysfs would be critical to system performance - though
perhaps that is just my ignorance.
Is there an obvious reason why I can't do this, or should I dive in and try
to implement it? (Or should I first just try to estimate how much memory it
would save, to find out whether it would be worth the complexity?)
Not subscribed to list; please Cc on replies.
--
-ed
Powered by blists - more mailing lists