Re: Performance issue due to constant "modprobes"

[Ed W <lists@wildgooses.com>]

On 08/04/2011 01:47, Maciej Żenczykowski wrote:
>> 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.

Thanks - very helpful!

It was easiest for me to patch my iptables with just your commit and my
results are very promising:

Starting "shorewall"
- using busybox modprobe + released iptables = several minutes...
- module-init-tools + released iptables = 12s
- module-init-tools + your commit = 7.7s
- module-init-tools + patching out modprobe completely = 4.9s

So, whilst your patch has a huge positive benefit, I'm still seeing a
substantial amount of cpu going to useless modprobing.

I don't see an immediate solution, *unless* there is some way to ask the
kernel if some module is already compiled in? I don't immediately see
that this is possible and google didn't turn anything up? I guess the
various xtables modules could export something that allows them to be
detected as loaded, but I sense that this is unlikely to be an
acceptable patch unless others have shown that there is a performance
problem?

Of the rest of my 4.9s, 97% of that is waiting for iptables and tc to do
stuff.  I need to profile further to see where the delays are though

Thanks for your commit above - extremely helpful - grateful if you might
consider whether there is some way to avoid any modprobes at all? (Note
that the -M option appears not to work in iptables at present?)

Thanks

Ed W


--
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