Re: [14/14] vcompound: Avoid vmalloc for ehash_locks

Re: [14/14] vcompound: Avoid vmalloc for ehash_locks

[Eric Dumazet]

Christoph Lameter a écrit :
> Avoid the use of vmalloc for the ehash locks.
> 
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
> 
> ---
>  include/net/inet_hashtables.h |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.25-rc5-mm1/include/net/inet_hashtables.h
> ===================================================================
> --- linux-2.6.25-rc5-mm1.orig/include/net/inet_hashtables.h	2008-03-20 22:21:02.680501729 -0700
> +++ linux-2.6.25-rc5-mm1/include/net/inet_hashtables.h	2008-03-20 22:22:15.416565317 -0700
> @@ -164,7 +164,8 @@ static inline int inet_ehash_locks_alloc
>  	if (sizeof(rwlock_t) != 0) {
>  #ifdef CONFIG_NUMA
>  		if (size * sizeof(rwlock_t) > PAGE_SIZE)
> -			hashinfo->ehash_locks = vmalloc(size * sizeof(rwlock_t));
> +			hashinfo->ehash_locks = __alloc_vcompound(GFP_KERNEL,
> +				get_order(size * sizeof(rwlock_t)));
>  		else
>  #endif
>  		hashinfo->ehash_locks =	kmalloc(size * sizeof(rwlock_t),
> @@ -185,7 +186,7 @@ static inline void inet_ehash_locks_free
>  		unsigned int size = (hashinfo->ehash_locks_mask + 1) *
>  							sizeof(rwlock_t);
>  		if (size > PAGE_SIZE)
> -			vfree(hashinfo->ehash_locks);
> +			__free_vcompound(hashinfo->ehash_locks);
>  		else
>  #endif
>  		kfree(hashinfo->ehash_locks);
> 

But, isnt it defeating the purpose of this *particular* vmalloc() use ?

CONFIG_NUMA and vmalloc() at boot time means :

Try to distribute the pages on several nodes.

Memory pressure on ehash_locks[] is so high we definitly want to spread it.

(for similar uses of vmalloc(), see also hashdist=1 )

Also, please CC netdev for network patches :)

Thank you

Re: [14/14] vcompound: Avoid vmalloc for ehash_locks

[Christoph Lameter]

On Fri, 21 Mar 2008, Eric Dumazet wrote:

> But, isnt it defeating the purpose of this *particular* vmalloc() use ?

I thought that was controlled by hashdist? I did not see it used here and 
so I assumed that the RR was not intended here.

Re: [14/14] vcompound: Avoid vmalloc for ehash_locks

[David Miller]

From: Christoph Lameter <clameter@sgi.com>
Date: Fri, 21 Mar 2008 00:03:51 -0700 (PDT)

> On Fri, 21 Mar 2008, Eric Dumazet wrote:
> 
> > But, isnt it defeating the purpose of this *particular* vmalloc() use ?
> 
> I thought that was controlled by hashdist? I did not see it used here and 
> so I assumed that the RR was not intended here.

It's intended for all of the major networking hash tables.

Re: [14/14] vcompound: Avoid vmalloc for ehash_locks

[Eric Dumazet]

David Miller a écrit :
> From: Christoph Lameter <clameter@sgi.com>
> Date: Fri, 21 Mar 2008 00:03:51 -0700 (PDT)
> 
>> On Fri, 21 Mar 2008, Eric Dumazet wrote:
>>
>>> But, isnt it defeating the purpose of this *particular* vmalloc() use ?
>> I thought that was controlled by hashdist? I did not see it used here and 
>> so I assumed that the RR was not intended here.
> 
> It's intended for all of the major networking hash tables.

Other networking hash tables uses alloc_large_system_hash(), which handles 
hashdist settings.

But this helper is __init only, so we can not use it for ehash_locks (can be 
allocated by DCCP module)

Re: [14/14] vcompound: Avoid vmalloc for ehash_locks

[David Miller]

From: Eric Dumazet <dada1@cosmosbay.com>
Date: Fri, 21 Mar 2008 08:02:11 +0100

> But, isnt it defeating the purpose of this *particular* vmalloc() use ?
> 
> CONFIG_NUMA and vmalloc() at boot time means :
> 
> Try to distribute the pages on several nodes.
> 
> Memory pressure on ehash_locks[] is so high we definitly want to spread it.
> 
> (for similar uses of vmalloc(), see also hashdist=1 )
> 
> Also, please CC netdev for network patches :)

I agree with Eric, converting any of the networking hash
allocations to this new facility is not the right thing
to do.

Re: [14/14] vcompound: Avoid vmalloc for ehash_locks

[Christoph Lameter]

On Fri, 21 Mar 2008, David Miller wrote:

> I agree with Eric, converting any of the networking hash
> allocations to this new facility is not the right thing
> to do.

Ok. Going to drop it.