mrjbom wrote:
I try to follow this rule, favoring understanding over performance.
At the same time, I wouldn't want to lose too much performance.
Write the simple algorithm you understand. Then see if the performance is OK. If not, then measure where the slowdowns are. If experience has taught me anything here, it is that developers are incapable of gauging performance bottlenecks. They are never where you think they are. So measure twice, that way at least you have some way to know.
mrjbom wrote:
So, I would probably prefer to use malloc for all things in the kernel since it's easier, however I don't know how much worse it is compared to general purpose malloc.
The kernel has special needs compared to an application. Quite a few allocations require specific regions of physical memory. And the kernel often operates on objects that are quite costly to construct and destroy, and much cheaper to be left lying around and reused later. But only until memory gets scarce, of course. So while a normal malloc implementation is likely fine, you will need to build things on top of it, or maybe build some memory management directly on top of the physical and virtual allocators.
Speaking of malloc, all of the implementations I know depend on something to get more memory, so you will have to implement some way to do that as well.