Hi,
jnc100 wrote:
Do you mean regions e.g. text, data, bss, stack and heap or do you mean supporting a malloc-like interface within the heap. I can only comment on a bitmap based system, but if you're talking about a malloc interface, remember it is possible to call malloc(1) asking for only one byte. This would mean you need to represent every byte with a bit in the lowest buddy, or in other words use up almost a quarter of the total heap size with buddies.
It's common for malloc to allocate 8 bytes when asked to allocate less (and also common for malloc to "round up" to the nearest 8 byte boundary), for alignment purposes.
jnc100 wrote:
So after arguing that size isn't important for buddies to represent physical memory, I'm now arguing the exact opposite for virtual memory!
This is because the total amount of virtual memory in a machine is 4GB * no. of processes (or far larger for long mode), whereas the physical memory where you actually store the structures is much less.
Not quite - the amount of space being managed by malloc depends on the process, and it doesn't manage the entire 4 GB (or 3 GB?). For example, malloc might start managing 16 MB of space, and get more space/RAM if it needs to, and free space/RAM when it can.
For physical memory management, the first thing you'd need to decide is if you care about where pages are allocated. Most physical memory allocations are 4 KB and it doesn't matter where the page comes from. Free page stack/s are the best option for this case - they're extremely fast and only costs 4 bytes (plus 4 bytes per free page, that's stored in otherwise free RAM and therefore doesn't matter).
Buddy allocators, bitmaps, etc should only be used if the location of allocated pages matters. Typically this is only for DMA buffers, which represent a small number of allocations and a small amount of RAM. IMHO it makes sense to split physical memory into several zones, and use free pages stack/s in one zone to make the common case fast and efficient, and use a buddy allocator or something in another zone for when the location of allocated pages matter. For example, I normally use a bitmap for memory below 16 MB, and free page stacks for anything above 16 MB.
The only other consideration for physical memory is CPU caches, where a physical page needs to go in a certain area of the cache and it's better to be using different areas of the cache instead of the same area of the cache. To get around this some OSs use page colouring (e.g. one free page stack per page colour).
AFAIK Linux doesn't support page colouring, so contiguous linear pages might be using physical pages that use the same part of the cache, which reduces cache efficiency. To get around this they (mis)use a buddy allocator to reduce the problem (so that contiguous linear pages are more likely to be contiguous physical pages, which use differnt parts of the cache). Also, Linux wastes most of the first 16 MB of RAM by storing a large (4 MB or more) kernel in it, so having a specific area of physical memory for allocations that need contiguous physical pages doesn't work so well. IMHO these poor design descisions makes a buddy allocators one of the best options for Linux, but without the poor design descisions a buddy allocator may not be the best option...
Cheers,
Brendan