Messages in this thread | | | Date | Tue, 03 Nov 2009 07:14:33 +0100 | From | Eric Dumazet <> | Subject | Re: [PATCH 1/3] sysfs directory scaling: rbtree for dirent name lookups |
| |
Greg KH a écrit : > On Sun, Nov 01, 2009 at 11:31:30AM -0500, Benjamin LaHaise wrote: >> Use an rbtree in sysfs_dirent to speed up file lookup times >> >> Systems with large numbers (tens of thousands and more) of network >> interfaces stress the sysfs code in ways that make the linear search for >> a name match take far too long. Avoid this by using an rbtree. > > What kind of speedups are you seeing here? And do these changes cause a > memory increase due to the structure changes which outweigh the > speedups? > > What kind of test are you doing to reproduce this? >
Its curious because in my tests the biggest problems come from kernel/sysctl.c (__register_sysctl_paths) consuming 80% of cpu in following attempt to create 20.000 devices
(disable hotplug before trying this, and ipv6 too !) modprobe dummy numdummies=20000
I believe we should address __register_sysctl_paths() scalability problems too.
I dont know what is the 'sentinel' we allocate after each struct ctl_table But I suspect we could reduce size requirement of the 'sentinel' to include only needed fields for the sentinel (and move them at start of ctl_table)
/* * For each path component, allocate a 2-element ctl_table array. * The first array element will be filled with the sysctl entry * for this, the second will be the sentinel (ctl_name == 0). * * We allocate everything in one go so that we don't have to * worry about freeing additional memory in unregister_sysctl_table. */ header = kzalloc(sizeof(struct ctl_table_header) + (2 * npath * sizeof(struct ctl_table)), GFP_KERNEL);
Then, adding an rb_node in ctl_table_header to speedup __register_sysctl_paths() a bit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |