Re: RFC: turn kmalloc+memset(,0,) into kcalloc

From: Adrian Bunk (bunk_at_stusta.de)
Date: 04/08/05

  • Next message: Miss Binta Wahid.: "Assalam Alaikum" 
    Date:	Fri, 8 Apr 2005 15:00:08 +0200
To: Paulo Marques <pmarques@grupopie.com>

    On Fri, Apr 08, 2005 at 01:38:22PM +0100, Paulo Marques wrote:
    > Adrian Bunk wrote:
    > >On Tue, Apr 05, 2005 at 05:26:31PM +0100, Paulo Marques wrote:
    >
    > Hi Adrian,

    Hi Paolo,

    > >>[...]
    > >>pros:
    > >> - smaller kernel image size
    > >> - smaller (and more readable) source code
    > >
    > >Which is better readable depends on what you are used to.
    >
    > That's true to some degree, but look at code like this (in
    > drivers/usb/input/hid-core.c):
    >
    > > if (!(field = kmalloc(sizeof(struct hid_field) + usages *
    > > sizeof(struct hid_usage)
    > > + values * sizeof(unsigned), GFP_KERNEL))) return NULL;
    > >
    > > memset(field, 0, sizeof(struct hid_field) + usages * sizeof(struct
    > > hid_usage)
    > > + values * sizeof(unsigned));
    >
    > and compare to this:
    >
    > > field = kzalloc(sizeof(struct hid_field) + usages * sizeof(struct
    > > hid_usage)
    > > + values * sizeof(unsigned), GFP_KERNEL);
    > > if (!field)
    > > return NULL;
    >
    > In the first case you have to read carefully to make sure that the size
    > argument in both the kmalloc and the memset are the same. Even more, if
    > the size needs to be updated to include something more, a mistake can be
    > made by inserting the extra size just in the kmalloc call. Also, you are
    > assuming that the compiler is smart enough to notice that the two
    > expressions are the same and cache the result, but this is probably true
    > for gcc, anyway.
    >
    > I think most will agree that the second piece of code is more "readable".

    In this case yes (but it could still use the normal kcalloc).

    >...
    > >There are tasks of higher value that can be done.
    >
    > I couldn't agree more :)
    >
    > >E.g. read my "Stack usage tasks" email. The benefits would only be
    > >present for people using GNU gcc 3.4 or SuSE gcc 3.3 on i386, but this
    > >is a reasonable subset of the kernel users - and it brings them a
    > >2% kernel size improvement.
    >
    > I've read that thread, but it seems that it is at a dead end right now,
    > since we don't have a good tool to find out which functions are abusing
    > the stack with unit-at-a-time.
    >
    > Is there some way to even limit the search, like using a stack usage log
    > from a compilation without unit-at-a-time, and going over the hotspots
    > to check for problems?
    >
    > If we can get a list, even if it contains a lot of false positives, I
    > would more than happy to help out...

    Joerg's list of recursions should be valid independent of the kernel
    version. Fixing any real stack problems [1] that might be in this list
    is a valuable task.

    And "make checkstack" in a kernel compiled with unit-at-a-time lists
    several possible problems at the top.

    > Paulo Marques

    cu
    Adrian

    [1] there are cases in this list that aren't a problem e.g. because of
        an obviously limited recursion 

    -- 
       "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/
  • Next message: Miss Binta Wahid.: "Assalam Alaikum"

    Relevant Pages

    • Re: 2.6.13-rc4-mm1
      ... > Adrian Bunk wrote: ... >>It moved to a different header file. ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: missing license tag in intermodule.
      ... Acked-by: Adrian Bunk <bunk@xxxxxxxxx cu ... There had been need of rain for many days. ... 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/ ...
      (Linux-Kernel)
    • Re: [2.6 patch] drivers/net/hamradio/: cleanups
      ... > Adrian Bunk wrote: ... Can you give me a hint how it should be used? ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [2.6 patch] drivers/char/tty_io.c: remove console_use_vt
      ... > On Mon, Jan 31, Adrian Bunk wrote: ... There had been need of rain for many days. ... Pearl S. Buck - Dragon Seed ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [2.6 patch] schedule obsolete OSS drivers for removal
      ... On Tuesday 26 July 2005 14:13, Adrian Bunk wrote: ... >Why doesn't the ALSA driver work for you? ... Copyright 2005 by Maurice Eugene Heskett, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)