Bug 9736

Summary:	regression: sysctl_check changes in 2.6.24 are O(n) resulting in slow creation of 10000 network interfaces
Product:	Networking	Reporter:	Rafael J. Wysocki (rjw)
Component:	Other	Assignee:	Arnaldo Carvalho de Melo (acme)
Status:	REJECTED WILL_NOT_FIX
Severity:	normal	CC:	ebiederm, penberg, protasnb
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.24-rc	Subsystem:
Regression:	Yes	Bisected commit-id:
Bug Depends on:
Bug Blocks:	9243

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?