Le mardi 13 avril 2010 à 19:06 +0800, Changli Gao a écrit : > On Tue, Apr 13, 2010 at 6:09 PM, Patrick McHardy <kaber@xxxxxxxxx> wrote: > > Changli Gao wrote: > >> use hash table to speed up entry finding. > >> > >> If verdicts aren't received in order, list isn't efficient, and hash > >> table is better. > > > > Any what is the advantage of using flex arrays compared to a simple > > open code hash table? > > > > From Documentation/flexible-arrays.txt > > Large contiguous memory allocations can be unreliable in the Linux kernel. > Kernel programmers will sometimes respond to this problem by allocating > pages with vmalloc(). This solution not ideal, though. On 32-bit systems, > memory from vmalloc() must be mapped into a relatively small address space; > it's easy to run out. On SMP systems, the page table changes required by > vmalloc() allocations can require expensive cross-processor interrupts on > all CPUs. And, on all systems, use of space in the vmalloc() range > increases pressure on the translation lookaside buffer (TLB), reducing the > performance of the system. > > User may create lots of queues, which have large hash tables. Flex > array has better scalability than vmalloc() and kmalloc(). > Thats theory. And for sparse arrays, that pro might be true. In your case, you prealloc all the array, using more ram than vmalloc... In practice, x86 cpu can access vmalloced() data much faster then flex_array_managed data (take a look at all the expensive divides in flex code... :'( ) If vmalloc() happens to be slow, it can trivially be extended to use huge pages too. It will happen one day, when/if necessary. -- 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
