On Thu, Apr 7, 2011 at 16:16, Ed W <lists@xxxxxxxxxxxxxx> wrote: > Hi, I am using a relatively low powered (embedded) platform and I have a > significant performance problem due to slow "modprobe" performance. > > I have my kernel compiled without modules. ÂMy modprobe takes a little > under 1ms to execute. Â"iptables" appears to try and modprobe some 21 > match/target modules. ÂAs a result, even "iptables -h" takes around 14ms > to run. ÂThis is adding some substantial time to my firewall setup time > (hacking out the modprobes reduces run time from the 14ms to near zero, > ie it's 90+% of my runtime) > > I have dug through the code a bit and the first thing I notice is that > there is no --modprobe option actually parsed for, and the undocumented > "-M" option doesn't appear to pass through to xtables.c? (I thought > about simply lying about the modprobe binary name) > > My next thought was to collect all the modprobes and run them with a > single execution (modprobe -a). However, it's not clear to me whether > it's important that the modprobe occurs in the middle of xtables.c / > compatible_revision() ? > > The final thought is whether it's possible to notice that a module is > already loaded and skip the modprobe call altogether? (/proc/modules is > not enough because the module could be built into the kernel) > > Does someone have any ideas on how I can finesse these constant (and > expensive in my case) modprobes each time we run the iptables command? Could you try with an iptables built from iptables git master branch? I believe a recent change I submitted (delayed initialization of target/matches to prevent module autoloading) may actually fix your problem. - Maciej -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
