Re: [RFC] fib_trie: memory waste solutions

[Eric Dumazet <dada1@cosmosbay.com>]

Andi Kleen a écrit :
> On Mon, Apr 07, 2008 at 04:42:35PM +0200, Robert Olsson wrote:
>   
>> Andi Kleen writes:
>>
>>  > >  Do we get slower with vmalloc due to TLB-lookups etc? Guess this
>>  > >  should be investigated.
>>  > 
>>  > In some cases it might even go faster because a lot of x86 CPUs
>>  > have far more 4K TLBs than 2M TLBs. vmalloc is just quite expensive
>>  > in setup/free time, but that shouldn't be a big issue here.
>>
>>
>>  I've did some rDoS testing and the lookup performance is the same or 
>>  slightly better. So it should be fine.  
>>     
>
> If you want more realistic worst case numbers run something in user space in 
> the background that thrashes the TLBs constantly and then see how
> the numbers change.
>
> The main advantage of using large pages is that they tend to be separated
> from 4K TLBs and since most user space doesn't use large pages it 
> gives the kernel an effective private TLB pool.
>
> With vmalloc it will now compete with whatever other TLB pigs are active.
>   
Yes, but with vmalloc(), NUMA machines have some chance to distribute 
this big area on several nodes

(only if the process currently expanding the fib_trie root node has an 
appropriate numa_policy.... ah well :) :) )