Re: [PATCH]use kzalloc in vfs where appropriate

From: Oliver Neukum
Date: Sun Mar 19 2006 - 15:47:58 EST


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/