Messages in this thread |  | | Date | Sun, 19 May 96 16:36:58 EDT | From | Tom Dyas <> | Subject | Re: 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
|  |