Hi,
bace wrote:
This is how I think it works:
1. A physical memory allocator provides frame_alloc(pages) and frame_free(position, pages), which allocates physical memory in blocks of however big a page on the system architecture is. This can be implemented with a bitset, a stack, a buddy allocator, etc.
2. A virtual address allocator provides page_alloc(pages) and page_free(position, pages), which allocates virtual memory addresses in blocks of however big a page on the system architecture is, making use of frame_alloc() and frame_free(). This can be implemented with ???.
3. Finally, the memory allocator itself provides malloc(size) and free(position), which allocates virtual memory of any size. This can be implemented in several ways, and the code is usually linked with program binaries. This makes use of page_alloc() and page_free() through system calls (or directly for the kernel's memory allocator).
That looks mostly right to me; however...
From the kernel's point of view; that final memory allocator should be considered part of the process. It could be "malloc()" and "free()" in a dynamically linked library, it could be something completely different (e.g. garbage collector), and it could also be "nothing" (e.g. programmer explicitly manages their own memory). A kernel doesn't need to know or care what the final memory allocator is.
bace wrote:
Combuster wrote:
Roflo wrote:
Allocating free virtual pages can be done by looping through the page directory and find free pages (or finding free page tables, representing 1024 free pages).
In general, if you want map something into virtual space without knowing which address to use for it or if it's free, your logic is flawed to start with.
So, is it the program's job to choose where the physical memory is mapped to in the virtual address space? That doesn't seem right...?
Once the process is started; the final memory allocator (the one the kernel doesn't know or care about, which is part of the process) would decide which virtual addresses are used for what.
The second "virtual address allocator" is more like a memory manager than an allocator. For example, it might have a set of attributes for each page (e.g. if the page is meant to look like RAM, if the page can/can't be sent to swap space, if the page is part of a memory mapped file, if the page is executable or writeable, etc) and provide a single "change n pages starting at <address> to type <attributes>" function that the third memory allocator uses to do things like changing an area to "meant to look like RAM" or changing an area back to "not meant to look like RAM".
Cheers,
Brendan