Re: Performance issue due to constant "modprobes"

["Maciej Żenczykowski" <zenczykowski@gmail.com>]

On Thu, Apr 7, 2011 at 16:16, Ed W <lists@wildgooses.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html