Re: [PATCH]use kzalloc in vfs where appropriate

[Oliver Neukum]

Am Sonntag, 19. MÃrz 2006 17:09 schrieb Arjan van de Ven:
> On Sun, 2006-03-19 at 14:29 +0100, Oliver Neukum wrote:
> > Am Samstag, 18. MÃrz 2006 11:55 schrieb Arjan van de Ven:
> > > On Sat, 2006-03-18 at 11:44 +0100, Oliver Neukum wrote:
> > > > Am Freitag, 17. MÃrz 2006 22:08 schrieb Matthew Wilcox:
> > > > > On Fri, Mar 17, 2006 at 09:58:14PM +0100, Oliver Neukum wrote:
> > > > > > --- a/fs/bio.c	2006-03-11 23:12:55.000000000 +0100
> > > > > > +++ b/fs/bio.c	2006-03-17 16:44:49.000000000 +0100
> > > > > > @@ -635,12 +635,10 @@
> > > > > >  		return ERR_PTR(-ENOMEM);
> > > > > >  
> > > > > >  	ret = -ENOMEM;
> > > > > > -	pages = kmalloc(nr_pages * sizeof(struct page *), GFP_KERNEL);
> > > > > > +	pages = kzalloc(nr_pages * sizeof(struct page *), GFP_KERNEL);
> > > > > 
> > > > > Didn't we just discuss this one and conclude it needed to use kcalloc
> > > > > instead?
> > > > 
> > > > I've found some discussion in the archive, but no conclusion. Could you
> > > > elaborate?
> > > 
> > > kcalloc is the array allocator.
> > > Here.. you're allocating an array of nr_pages worth of pointers.
> > > kcalloc does extra checks because it KNOWS it's an array...
> > 
> > I see. A patch is coming.
> > Shouldn't this check from slab.h:
> > 
> > 	if (n != 0 && size > INT_MAX / n)
> > 		return NULL;
> > 
> > carry an "unlikely"?
> 
> gcc is most likely smart enough for that already, and most of the time n
> is a compile time constant already :)

Yes it is. The generated code is identical. But on second thought this is still
not optimal. A full division is generated:

	xorl	%edx, %edx
	movl	$2147483647, %eax
	movq	$0, 40(%rsp)
	divq	%rcx
	movl	$8, %edx
	cmpq	%rax, %rdx
	ja	.L313

Rewriting the test as:
n!=0 && n > INT_MAX / size
saves the division because size is much likelier to be a constant, and indeed
the code is better:

	cmpq	$268435455, %rax
	movq	$0, 40(%rsp)
	ja	.L313

Is there anything I am missing?

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