Re: dynamic sysctl registration (pre2.0).4
Tom Dyas (tdyas@gandalf.rutgers.edu)
Sun, 19 May 96 16:36:58 EDT
> 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