On Thursday 2010-11-18 16:43, Eric Dumazet wrote: >Le jeudi 18 novembre 2010 Ã 22:39 +0800, Changli Gao a Ãcrit : >> As only xt_counters are private to each CPU, we don't need to maintain >> a whole individual table for each CPU. >> >> In the kernel space, we use the memory of ipt_entry.counters to save a >> pointer to a percpu xt_counters. When iptables runs, it only update the >> counters on its own CPU. >> >> On non SMP platforms, no change is made. >> >> Only the code of iptables is converted. Thanks for reviews. >> > >Changli > >I answered you a (difficult) work was in progress Was it? Quoting Patrick from 24h prior to this post: |so patches to get rid of the table duplication are highly welcome. >still you post a patch that needs our review and time ? This is crazy. You do not need to do it, but I will happily look at this. Of course my observations are the same as yours: >Your way of allocating a percpu counter for each counter is a pure TLB >and cache line blower (up to two cache lines per counter), not counting >the time needed to load a new table with 10.000 entries. Some people >still use scripts with hundred of calls to iptables. The two are statistically independent though. Even for a loaded ruleset, the TLB/DC miss accumulation will be desastrous - as I've found with linked-list rules/small allocs. >Allocating one contiguous percpu var for all counters is a must. > >Problem is : percpu alloc doesnt allow big allocations. > >#define PCPU_MIN_UNIT_SIZE PFN_ALIGN(32 << 10) > >So max allocation is 32 Kbytes, thats 2048 'xt_counters' only. >-> cannot really use pcpu-alloc, but a kmalloc_node() or vmalloc_node() >per cpu .. as is already done for jumpstack ;-) -- 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
