allocating frames using buddy allocation

[LtG]

This is obvious, what i meant is suppose you have a region sized X, X / PAGE_SIZE = 2^N. So basically a buddy allocator can divide this region 2^N times. For each time it divides it, you'll need another struct.(as they're now buddies, not the same region).

Maybe I'm still missing the point, but isn't the answer essentially the same, assume the worst (like each region is only one page)? So the number of "buddies" has to be assume to be as high as possible and then multiply that with the size of a single buddy..

[Sourcer]

This is obvious, what i meant is suppose you have a region sized X, X / PAGE_SIZE = 2^N. So basically a buddy allocator can divide this region 2^N times. For each time it divides it, you'll need another struct.(as they're now buddies, not the same region).

Maybe I'm still missing the point, but isn't the answer essentially the same, assume the worst (like each region is only one page)? So the number of "buddies" has to be assume to be as high as possible and then multiply that with the size of a single buddy..

Well my point is that it's a lot of memory :S
Also, BIOS can report overlapping memory? thats new to me.

[LtG]

Well my point is that it's a lot of memory :S
Also, BIOS can report overlapping memory? thats new to me.

According to Wiki:

In reality, this function returns an unsorted list that may contain unused entries and (in rare/dodgy cases) may return overlapping areas.

GRUB/Multiboot might have sanitized it for you, but it might not have. The only safe thing to do is do it yourself. So assume essentially nothing and sanitize/"normalize" it, so that when you actually use the memory map you don't have to worry about dozens of edge cases making your code much more complex, error prone and slower.

This is actually one of the harder chicken-and-egg problems for me since you need some memory to do the normalization in but you have no way of easily knowing how much memory that is (similar to your problem here =)). My current way isn't very good since it assumes a certain max number of entries, I'll need to fix that at some point. So if there was a pathological system that spat out 1M entries in the memory map I wouldn't be able to use all that memory.

PS. Maybe there should be some collective effort to do the memory map normalization properly which everyone can use since I guess it's one of the few things that there shouldn't be much variation between all our OS's..

[Sourcer]

Well my point is that it's a lot of memory :S
Also, BIOS can report overlapping memory? thats new to me.

According to Wiki:

In reality, this function returns an unsorted list that may contain unused entries and (in rare/dodgy cases) may return overlapping areas.

GRUB/Multiboot might have sanitized it for you, but it might not have. The only safe thing to do is do it yourself. So assume essentially nothing and sanitize/"normalize" it, so that when you actually use the memory map you don't have to worry about dozens of edge cases making your code much more complex, error prone and slower.

This is actually one of the harder chicken-and-egg problems for me since you need some memory to do the normalization in but you have no way of easily knowing how much memory that is (similar to your problem here =)). My current way isn't very good since it assumes a certain max number of entries, I'll need to fix that at some point. So if there was a pathological system that spat out 1M entries in the memory map I wouldn't be able to use all that memory.

PS. Maybe there should be some collective effort to do the memory map normalization properly which everyone can use since I guess it's one of the few things that there shouldn't be much variation between all our OS's..

Not sure if theres a better way of doing it other than assuming you're going to get MAX entries. Linux does it this way too..