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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
