Hi,
I like the attempt to use virtual memory management tricks in kernel-space (I wish more people would try); but unfortunately for this specific case...
zaptor wrote:
Are there any downsides to doing it this way (as opposed to allocating the backing frames for the bitmap up front?
When there's a lot of free RAM it doesn't matter if you use RAM for the bitmap because that RAM would have been free/wasted/unused anyway, and when there's very little free RAM the bitmap must have already been created. Essentially, as physical memory goes from "lots of free RAM" to "very little free RAM" (e.g. during boot and soon after when apps start getting used) there isn't an instance in time where dynamically extending the bitmap helps physical memory usage.
It might allow you to boot a little faster (by postponing the creating of the bitmap) but you'd be saving a small amount of time during boot (where you can do "wholesale bulk initialisation" efficiently) and it'll be costing you a lot more time later in boot (where you're paying for the additional costs of page faults and doing "one page of bitmap at a time initialisation"); so that's not really a great compromise either.
The other thing is that it'd be a more complex (higher risk of bugs, higher cost of maintenance); and this is where it starts getting scary (e.g. imagine there's multiple CPUs and you need a lock protecting the bitmap because a "lock-free" approach is too hard when you're dynamically extending the bitmap).
zaptor wrote:
What is the recommended way of allocating memory for the physical frame bitmap?
The recommended way is to not use a bitmap, at least not for all of physical memory.
Note that the physical memory map is "multiple discontinuous blobs of usable RAM" - e.g. for a simple system (no NUMA or anything) you might have ~3 GiB (with various pieces taken out of the first 1 MiB for legacy stuff) then a large 1 GiB gap (for PCI hole, HPET and APIC, system ROM) then another GiB of usable RAM (with a few more small pieces taken out for ACPI areas, etc).
For a single bitmap; for optimised searching (e.g. keeping track of "lowest potentially free page" to reduce the area to search, combined with an outer loop used to check 64 bits at once) it still ends up being expensive (e.g. think of all the cache misses as you plow through large areas of "will never be usable RAM").
If you do use a single bitmap; I'd strongly recommend generating the whole bitmap during boot; and I'd consider using the same "single physical page full of zeros" for any of the "will never be usable RAM" areas that are large enough (to reduce physical memory used by the bitmap a little and reduce some of the cache misses and cache pollution as you search through large gaps).
Cheers,
Brendan