lkml.org 
[lkml]   [1996]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: dynamic sysctl registration (pre2.0).4
> OK, then.  Not picking on you specifically, but I'm curious in 
> general. What is so evil about kmalloc? From the 'detached observer'
> point of view, we seem to have one set of people saying 'kmalloc is fine',
> one set wishing to rewrite everything to avoid it, and a third set using it
> but pulling weird stunts with it to reduce the impact of things they
> consider undesirable (I'm thinking about the skb stuff here).
>
> Is the whole concept of a general memory allocator so deeply inefficient
> that it should be replaced with a million special-purpose routines, or
> is the concept fine and the implementation suboptimal? If the former,
> lets just write our 56-byte block allocator and save a page (well, it might
> please Paul Gortmaker :-) If the latter, why don't people fix the problem
> instead of introducing special-purpose workarounds all the time?
>
> I'm not trying to imply there necessarily _are_ any problems with it, I'm
> just asking why so many people think there are.

There is nothing wrong with kmalloc() per se. However, I do not think
it should be used for trivially small allocations when it can be
avoided. For example, in the sysctl code, we have a proc_dir_entry
associated with a struct ctl_table. Why do we need to kmalloc() the
proc_dir_entry when we can just make proc_dir_entry a member of struct
ctl_table?

Small allocations are bad because they have a higher chance of
fragmenting when they are freed. Thus, it is beneficial if we can
avoid small allocations whenever possible.

Tom


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.019 / U:2.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site