Re: [PATCH] kernel: use kcalloc instead kmalloc/memset

[Adrian Bunk <bunk@stusta.de>]

On Fri, Aug 05, 2005 at 09:52:32AM +0300, Pekka J Enberg wrote:
>...
> --- 2.6.orig/mm/slab.c
> +++ 2.6/mm/slab.c
> @@ -2555,6 +2555,20 @@ void kmem_cache_free(kmem_cache_t *cache
>  EXPORT_SYMBOL(kmem_cache_free);
>  
>  /**
> + * kzalloc - allocate memory. The memory is set to zero.
> + * @size: how many bytes of memory are required.
> + * @flags: the type of memory to allocate.
> + */
> +void *kzalloc(size_t size, unsigned int __nocast flags)
> +{
> +	void *ret = kmalloc(size, flags);
> +	if (ret)
> +		memset(ret, 0, size);
> +	return ret;
> +}
> +EXPORT_SYMBOL(kzalloc);
> +
> +/**
>   * kcalloc - allocate memory for an array. The memory is set to zero.
>   * @n: number of elements.
>   * @size: element size.
> @@ -2567,10 +2581,7 @@ void *kcalloc(size_t n, size_t size, uns
>  	if (n != 0 && size > INT_MAX / n)
>  		return ret;
>  
> -	ret = kmalloc(n * size, flags);
> -	if (ret)
> -		memset(ret, 0, n * size);
> -	return ret;
> +	return kzalloc(n * size, flags);
>  }
>  EXPORT_SYMBOL(kcalloc);


Looking at how few is left from kcalloc, can't we make it a
"static inline" function in slab.h?

This would optimize nicely for all of the users where the first or even 
the first two parameters are constant at compile-time and shouldn't do 
much harm for the other users.

As a side effect, the difference between kcalloc(1, ...) and kzalloc() 
would become a coding style question without any effect on the generated 
code.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/