Rick Jones a écrit : >>> I will give it a try and let folks know the results - unless told >>> otherwise, I will ass-u-me I only need rerun the "full_iptables" test >>> case. >> >> >> The runemomniagg2.sh script is still running, but the initial cycles >> profile suggests that the main change is converting the write_lock >> time into spinlock contention time with 78.39% of the cycles spent in >> ia64_spinlock_contention. When the script completes I'll upload the >> profiles and the netperf results to the same base URL as in the >> basenote under "contrack01/" > > The script completed - although at some point I hit an fd limit - I > think I have an fd leak in netperf somewhere :( . > > Anyhow, there are still some netperfs that end-up kicking the bucket > during the run - I suspect starvation because where in the other configs > (no iptables, and empty iptables) each netperf seems to consume about > 50% of a CPU - stands to reason - 64 netperfs, 32 cores - in the "full" > case I see many netperfs consuming 100% of a CPU. My gut is thinking > that one or more netperf contexts gets stuck doing something on behalf > of others. There is also ksoftirqd time for a few of those processes. > > Anyhow, the spread on trans/s/netperf is now 600 to 500 or 6000, which > does represent an improvement. > Yes indeed you have a speedup, tcp conntracking is OK. You now hit the nf_conntrack_lock spinlock we have in generic conntrack code (net/netfilter/nf_conntrack_core.c) nf_ct_refresh_acct() for instance has to lock it. We really want some finer locking here. -- 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
