Re: Performance issue due to constant "modprobes"

[Ed W <lists@wildgooses.com>]

On 09/04/2011 00:42, Jan Engelhardt wrote:
> 
> You said `iptables -h` itself would take a long time due to modprobe, 
> however, I can spot no invocation of it using `strace -fe execve 
> iptables -h` when the desired codes are already loaded into the kernel 
> one way or another.


Maciej pointed out this is the case for git as of around 4 days ago, and
in my last email I confirmed I saw the same.  I don't expect you to
observe what you say if you use last released 1.4.10?

However, if you use an xtables match then I would expect you to see a
module loaded? (For example running up a fairly vanilla "shorewall"
script manages to cause some 20 odd modules to load).  My specific
problem is that on my hardware, invoking modprobe takes some good few ms
(whether something is loaded or not), all modules are compiled into the
kernel, so this time is dead time.  In the case of shorewall (which for
sure is a beefy firewall script), this amounts to some several seconds
of wasted time (since nothing is loaded)

I appear to be able to eliminate this delay by modifying
/proc/sys/kernel/modprobe, but I not (apparently) by using "iptables -M
blah"? No one else is commenting on this, so either it's resolved in
current git, or ...?


No one has suggested anything, but basically, is there some way to avoid
running modprobe when the kernel has all the xtables modules compiled
in? ie can we detect that the code is already loaded and avoid trying to
probe for it?

However, many thanks to Maciej - that commit massively improves the
performance of the simple cases!

Cheers

Ed W