[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d120d5000609220645h3bdd2941p711c7419b50c6ea4@mail.gmail.com>
Date: Fri, 22 Sep 2006 09:45:30 -0400
From: "Dmitry Torokhov" <dmitry.torokhov@...il.com>
To: "Paulo Marques" <pmarques@...popie.com>
Cc: "Pekka Enberg" <penberg@...helsinki.fi>,
"Jiri Slaby" <jirislaby@...il.com>,
"Om Narasimhan" <om.turyx@...il.com>, linux-kernel@...r.kernel.org,
kernel-janitors@...ts.osdl.org
Subject: Re: [KJ] kmalloc to kzalloc patches for drivers/block [sane version]
On 9/22/06, Paulo Marques <pmarques@...popie.com> wrote:
> Pekka Enberg wrote:
> > On 9/22/06, Paulo Marques <pmarques@...popie.com> wrote:
> >> Agreed on every comment except this one. That complex expression is
> >> really just a constant in the end, so there is no point in using kcalloc.
> >
> > The code is arguably easier to read with kcalloc.
>
> I was afraid the kcalloc call would have the added overhead of an extra
> parameter and a multiplication, but since it is actually declared as a
> static inline, gcc should optimize everything away (because both
> parameters are constants) and give the same result in the end.
>
I think the we should follow a rule like this: when allocating several
separate objects of the same type at the same time (like 10 "card"
structures) kcalloc should be used. When allocating one object (even
consisting of "several ints") kmalloc/kzalloc should be used. As far
as I can see the code just tries to allocate longish bitmap and so
kzalloc is better.
Better yet, why don't you DECLARE_BITMAP(cmd_pool_bits) and embed it
right into struct ctrl_info instead of dynamically allocating it?
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists