Hi Ed:

Thank for taking the to look into this.

On 2/20/16 3:42 AM, Edward Cree wrote:
Testing this in a VM, and with udevd disabled (being too lazy to do it
  properly), created 1024 bridges.  On ls'ing
  /sys/class/net/bridge*/queues/*/, saw free memory drop by 64kB,
  suggesting that much had been saved by deferral.  It's not very much,
  hopefully deferring attribute groups will do better.

That sounds consistent with what I found by cutting out attributes in netdev_register_kobject. e.g., from my patch:

diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index b6c8a6629b39..f0df828a2f20 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -1524,7 +1524,8 @@ int netdev_register_kobject(struct net_device *ndev)
        int error = 0;

        device_initialize(dev);
-       dev->class = &net_class;
+       if (!netif_is_lwt(ndev))
+               dev->class = &net_class;
        dev->platform_data = ndev;
        dev->groups = groups;

@@ -1535,7 +1536,8 @@ int netdev_register_kobject(struct net_device *ndev)
        if (*groups)
                groups++;

-       *groups++ = &netstat_group;
+       if (!netif_is_lwt(ndev)) {
+               *groups++ = &netstat_group;

 #if IS_ENABLED(CONFIG_WIRELESS_EXT) || IS_ENABLED(CONFIG_CFG80211)
        if (ndev->ieee80211_ptr)


The big memory savings came in when I bypassed register_queue_kobjects:

        error = device_add(dev);
        if (error)
                return error;

-       error = register_queue_kobjects(ndev);
-       if (error) {
-               device_del(dev);
-               return error;
+       if (!netif_is_lwt(ndev)) {
+               error = register_queue_kobjects(ndev);
+               if (error) {
+                       device_del(dev);
+                       return error;
+               }
        }

        pm_runtime_set_memalloc_noio(dev, true);


Yes, this is a bit Draconian and does have impacts to tools looking for /sys files but the return is huge when you look at 1000's of netdevices (ports, vlans, bridges, bonds).


Reply via email to