Re: Performance issue due to constant "modprobes"

[Ed W <lists@wildgooses.com>]

On 13/04/2011 10:10, Maciej Żenczykowski wrote:
> I should probably point out that iptables module autoloading behaviour
> is very different for a pre-my commit statically compiled, non-shared
> iptables binary
> vs a post-my commit or non-statically compiled binary.

Aha.  I am using a static (well, --static --shared) iptables

> The modprobe issue would only show up if you had a statically
> compiled, non-shared iptables binary.
> ie. one where all the extensions were already part of the iptables
> binary and would always get initialized at startup (even for iptables
> -h).

Thanks - although my evidence suggests its simply the statically
compiled bit which is enough to trigger this?  My binary is both static
and shared (is that the correct term?)


> The fix would probably be in xtables.c in compatible_revision() to
> change everything starting with:
>   xtables_load_ko(xtables_modprobe_program, true);
> into a for loop:
> 
> something along the lines of
> 
> for (int load = 0; load <= 1; ++load) {
>   if (load) xtables_load_ko(...);
> 
>   ...
> 
>   and replace "close(sockfd); return 0;" with "if (load) {
> close(sockfd); return 0; }; continue;"
> 
> I'll try to write up and maybe even test a real patch tomorrow.

Thanks - although I'm not quite sure that I see that this changes
anything?  There is already a "static int load;" in, I think it's
xtables_load_ko (?) which prevents the module loading more than once per
call of iptables - I'm not sure I understand how your loop above changes
that?


Additionally, as helpfully pointed out by Jan, a chunk of my problem is
my static iptables apparently trying to probe a kernel module which
isn't incorporated into my kernel version.  I can't immediately see a
solution to not uselessly probing for that (without patching iptables)?
 Any ideas?

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