OSDev.org

Whether we realize it or not, every design decision we make is a trade-off, a certain combination of variables in different dimensions. The deficiencies of products when used in a particular context are often rooted in the fact that the producer made certain choices that turn out to be sub-optimal for the particular case at hand.

The best designs are those that leave crucial choices to the user, instead of "hardcoding" them. Why not have a memory management implementation that can be configured at build time or even selected through a kernel parameter, for example bitmap-based by default but changeable to a stack-based variant with frame recombining for those cases in which fragmentation happens over time?

Sometimes the best choice is not to choose at all

jbemmel wrote:Sometimes the best choice is not to choose at all

And leave it to the user? Would that add complexity?

Sometimes, the best choice is either the simplest (if the problem is not such a big deal and you have greater issues to worry about) or the 'good enough' choice (so you're not stuck dwelling on one thing that's holding up your OS.)

There's not really a good reason to ever want to configure the physical memory manager to use different data structures. What workloads really need that different of implementations? The things you want to be able to configure are things that could become bottlenecks for some workloads but be optimal for others- VM swapping algorithms, disk read/write scheduling, etc. As long as your PMM can provide the rest of your kernel what it needs (contiguous memory in particular regions? NUMA domains?) then your should be fine.