OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 12:19 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Coalescing memory managers?
PostPosted: Wed Jun 30, 2021 10:32 am 
Offline

Joined: Wed Jun 30, 2021 9:29 am
Posts: 7
I've written a physical page allocator using the buddy system. It took me a stupidly long time, as I'm currently managing collage, a degree change, etc. As such, I'd like to use it to it's full capability.

This would imply using an allocator for my kernel heap that can coalesce free chunks less then a page, so that if a page is filled with completely free chunks it can be used later for larger allocations over a page.

What could I use for this? I was thinking I could use the buddy system again for managing chunks in a page, putting the bitmaps on the front of each page used for small allocations, but that would lead to some memory overhead.

I really liked the concept of the fixed size allocator described here, however coalescing would probably be a pain in the @$$ performance wise.


Top
 Profile  
 
 Post subject: Re: Coalescing memory managers?
PostPosted: Wed Jun 30, 2021 6:31 pm 
Offline

Joined: Wed Jun 30, 2021 9:29 am
Posts: 7
While my post was getting approved I found I think would be best.
I'm going to have each chunk contain a header with a forward and backwards pointer to the last of that size, plus 8 more bytes to let free() know if it's allocated, the chunk size, and flags.
The last 8 bytes feels like a major waste, but I'm guessing it's best to be align to 8 bytes on my 64 bit system.
The chunk sizes are going be 2^n, from 32 bytes to 1 page. This size constraint is not only for quick access, but also helps split up larger chunks without wasted space at the end of page if need be.
Obviously, this solves my problem because I can simply check if the next chunk is free or not. There's 8 bytes of overhead per page when allocated, but I think that's fine.

I'm going to go forward with this, but if anyone sees this and thinks it's terrible, let me know.


Top
 Profile  
 
 Post subject: Re: Coalescing memory managers?
PostPosted: Thu Jul 01, 2021 5:33 am 
Offline
Member
Member

Joined: Tue Feb 18, 2020 3:29 pm
Posts: 1071
Your method doesn't seem bad, but most allocations will be 4K for your VMM to use, and 64K for ISA DMA usage. Having granularity less then 4K is typically not in a PMM. I plan on ignoring ISA DMA, and using a free stack. That will be very fast, yet super simple.

_________________
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg


Top
 Profile  
 
 Post subject: Re: Coalescing memory managers?
PostPosted: Thu Jul 01, 2021 2:23 pm 
Offline

Joined: Wed Jun 30, 2021 9:29 am
Posts: 7
Quote:
This would imply using an allocator for my kernel heap that can coalesce free chunks less then a page

Hopefully I'm not getting confused on what a VMM's purpose is, but I was meaning to say that this new allocator that splits up chunks is part of my (kernel space) VMM.

My idea of a VMM is this: you ask for memory using malloc, and it gives you about the size that you need, mapped into usable virtual address space.

On an unrelated note, is there any reason the kernel heap should be virtually continuous?
Right now, while things like my kernel code and stack are mapped somewhere else, I have all physical ram mapped linearly at 0xfffffff800000000. That way, I can do things like search the ACPI tables easily.

What could go wrong if my virtual allocator got the chunk it needed, and simply returned the address of the chunk in my mapping of physical ram?


Top
 Profile  
 
 Post subject: Re: Coalescing memory managers?
PostPosted: Thu Jul 01, 2021 3:29 pm 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
You might want to take a look at the big picture.

For example I use the same allocator for both the kernel heap and userspace, the only difference is the callback. From userspace, it calls mmap (through libc with a syscall), and when used in the kernel, it calls a function to map into kernelspace (direct function call).

indigo286 wrote:
On an unrelated note, is there any reason the kernel heap should be virtually continuous?
No, kernel heap does not need to be contiguous. Mine is, but only because my kernel never frees memory. Being a microkernel, it does not store lists that could change (device lists, process list, open file lists etc.), so all it needs is allocated on boot, hence kernel memory never gets fragmented and remains contiguous. But it could be fragmented, there's no constraint that would require contiguous kernel heap.

indigo286 wrote:
What could go wrong if my virtual allocator got the chunk it needed, and simply returned the address of the chunk in my mapping of physical ram?
For example that chunk isn't page aligned or not multiple of page size.

Cheers,
bzt


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot], rdos and 99 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group