Bug 9736 - regression: sysctl_check changes in 2.6.24 are O(n) resulting in slow creation of 10000 network interfaces
regression: sysctl_check changes in 2.6.24 are O(n) resulting in slow creatio...
Status: REJECTED WILL_NOT_FIX
Product: Networking
Classification: Unclassified
Component: Other
All Linux
: P1 normal
Assigned To: Arnaldo Carvalho de Melo
:
Depends on:
Blocks: 9243
  Show dependency treegraph
 
Reported: 2008-01-12 12:05 UTC by Rafael J. Wysocki
Modified: 2009-03-23 09:16 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.24-rc
Tree: Mainline
Regression: Yes


Attachments

Description Rafael J. Wysocki 2008-01-12 12:05:31 UTC
Subject         : regression: sysctl_check changes in 2.6.24 are O(n) resulting in slow creation of 10000 network interfaces
Submitter       : Benjamin LaHaise <bcrl@kvack.org>
Date            : 2008-01-06 23:03
References      : http://lkml.org/lkml/2008/1/6/248
Handled-By      : "Eric W. Biederman" <ebiederm@xmission.com>
Patch           : http://lkml.org/lkml/2008/1/7/60
Comment 1 Pekka Enberg 2008-02-15 13:28:38 UTC
Eric, I don't see this being fixed in mainline. Why is that?
Comment 2 Natalie Protasevich 2008-06-03 23:04:36 UTC
It appears that the code has been reworked and updated. Is the problem gone now?
Comment 3 Eric W. Biederman 2008-06-05 23:20:34 UTC
Registration of network devices in sysctl remains O(N).
Registration of network devices in sysfs is also O(N), apparently with a smaller constant.  So while I accept that this a bug I have a hard time swallowing that this is a regression.

sysctl_head_next is O(N) in the number of network devices registered, and thus all sysctl lookup operations are O(N).  sysctl_check_dir does a lookup each time we register a new sysctl name to see if we have duplicates (to catch the bugs like currently exist in the parallel port code).  Therefore this bug still exists.

For silly testing purposes you can compile out sysctl support entirely, or you can compile out the sysctl_check code if you select embedded and you don't need the protection.

To really fix this problem (which isn't a regression except in registration) the
sysctl internal data structures need to be completely redesigned.


Comment 4 Natalie Protasevich 2008-06-05 23:46:11 UTC
Thanks, Eric. Are there plans to such redesign? Is it about efficient lookup or something more evolved, any time frame for this?  

Note You need to log in before you can comment on or make changes to this bug.