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
Eric, I don't see this being fixed in mainline. Why is that?
It appears that the code has been reworked and updated. Is the problem gone now?
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.
Thanks, Eric. Are there plans to such redesign? Is it about efficient lookup or something more evolved, any time frame for this?