Hi,
bughunter wrote:
Brendan wrote:
The pages are "free", which means they aren't mapped into any address space, and therefore can't be accessed at all. The kernel itself can't easily access the free pages, but it doesn't need to - it knows the physical address of the page on the top of the stack, and can find the physical address for the second page on the stack when it allocates the first (and maps it into an address space). The same happens for freeing pages (store the old "top of stack" into the page, then remove the page from the address space and set a new "top of stack").
Do you have a picture illustrating how this works? What is done with the 4 bytes at the start of a page that points to the next page at allocation time? Are they zeroed, aren't they needed anymore?
The 4 bytes at the start of the page aren't needed once the page is allocated.
For allocating a page, you'd do something like:
Code:
allocLinearPage(void *linearAddress, type) {
uint32_t physPage;
physPage = top_of_stack;
map_page_into_page_table(physPage, linearAddress, type);
top_of_stack = *(uint32_t *)linearAddress;
*(uint32_t *)linearAddress = 0;
}
To free a page you'd do something like:
Code:
freeLinearPage(void *address) {
uint32_t physPage;
*(uint32_t *)linearAddress = top_of_stack;
physPage = get_phys_address_from_page_table(linearAddress);
top_of_stack = physPage;
remove_page_table_entry(linearAddress);
}
Of course this is simplified to show how it works without other clutter - it assumes there's one big free page stack and it's missing sanity checks, re-entrancy locking, etc. In practice I'd also seperate the physical memory manager from the linear memory manager, which is a little tricky - it involves having 3 functions: one to allocate a physical page, one to clean-up after allocating a physical page (after it's mapped into the address space), and one to free a physical page.
bughunter wrote:
Brendan wrote:
bughunter wrote:
Yes. But to allocate it dynamically, should there already be some PD?
Not really - you'd only need some basic physical memory management code that's used to setup paging and then thrown away.
So how does it go? pmm_Alloc() uses the PD when a PD is setup, what else does it do when you use pmm_Alloc() for the first time to setup a PD?
EDIT: If you read Kevin McGuire's first reply to my topic start post, he says I was correct that the Physical MM kallocpage() function should map an address in the PT. So there should be a PT and PD first to use kallocpage(), but you say I can use kallocpage() to allocate memory for a PD? Please understand me in that I'm a little bit confused here and there, I don't really see the overall picture anymore of how the whole PMM thing goes and how to initialize it. Maybe someone can draw a picture?
This depends on how you design your OS...
A long time ago I used to use a static PD and PT for the first process just to get things started. In the past I've implemented a full physical memory manager in real mode for pages below 4 GB (with many free page stacks, NUMA, page colouring, etc and a bitmap for memory below 16 MB). My newest design involves using a single free page stack during boot and then replacing pages with better pages once the kernel's physical memory manager and linear memory manager are running.
I use the "disposable boot time physical memory manager" for dynamically allocating all paging structures and all RAM used by the kernel's code and data, and then discard the boot code once the kernel is running (so that after boot there is nothing in RAM that wasn't dynamically allocated).
bughunter wrote:
Brendan wrote:
The hardware outside the CPU doesn't know anything about paging or linear addresses. This means that for ISA DMA transfers and some PCI bus-mastering devices, you have to use contiguous pages to transfer more than 4 KB. Free page stacks won't work because there's no way to make the pages contiguous (the order of pages on the stack ends up being the order that they were freed by what-ever had them last, which means you get "random" pages rather than contiguous pages). To make it worse, ISA DMA transfers can't cross a 64 KB boundary (and must be below 16 MB). For e.g. an 8 KB buffer can't use one page at 0x0000F000 and another at 0x00010000, even though the pages are contiguous and below 16 MB.
So Tim's tutorial on MM is wrong? He says you could setup a second stack for memory below 16MB.
I'm assuming you mean this:
[quote="Tim Robinson's Tutorial"]An alternative (which I believe is used by Linux and Windows NT) is to use a stack of pages. The (physical) addresses of free pages are pushed onto the stack; when a page is allocated, the next address is popped off the top of the stack and used. When a page is freed, its address is pushed back onto the top of the stack. With this, an allocation (or deallocation) becomes a matter of incrementing (or decrementing) some pointer. However, although most allocations don’t require the physical addresses to be continuous (the MMU can make discontinuous physical addresses continuous to user apps), things like DMA do. If something requires physical addresses to be continuous then the memory manager needs to take addresses out of the middle of
the stack, which complicates things.
The stack approach also makes it harder to choose where physical memory comes from. Returning to the DMA example, ISA DMA requires addresses to come from the first 16MB of memory (due to the 24-bit address bus). If we were to write a floppy drive controller driver, we’d need to allocate a buffer below the 16MB mark. A simple solution to this would be to maintain two stacks: one below 16MB, and one for the rest of memory. To take full advantage of the system’s memory we could take “mainâ€
Login
Register
FAQ
Search
