OSDev.org

Hi, I'm new osdever. And now I have already built a simple kernel support physic memory management by using buddy system.
And when I learnt some practical impelements for virtual memory management and paging, I found that most of those kernel only support less than 1GiB memory.
They mimic linux and map kernel address space to 0xC0000000. In such size less than 1 GiB, such as 256MiB or 896MiB, it is easy to map all address space from 0xC0000000 to 0xFFFFFFFF, and kernel can easily access whole memory space.

And now I find a problem in my kernel dev. Because I build a buddy system which can manage memory size up to 4GiB, and it will return physical address. If I follow such rule above, I can only use up to 1GiB memory even the physical memory is over 1GiB.
How can a good design to manage those unmapped memory over 1GiB? And if my function such as return a physical address, will the MMU automatically translate it to virtual address? If not, how to fix it?

Thank you very much!

bayesian wrote:How can a good design to manage those unmapped memory over 1GiB?

Since you brought up Linux, here's a description of how Linux deals with it. In short, the unmapped areas are temporarily mapped when the kernel needs to access them.

bayesian wrote:And if my function such as alloc_page_frame() return a physical address, will the MMU automatically translate it to virtual address?

The MMU only translates virtual addresses to physical addresses. Usually you don't need to translate physical addresses to virtual addresses, but if you do, the MMU won't help you.

bayesian wrote:If not, how to fix it?

I'm not sure I see the problem with having alloc_page_frame() return a physical address. Isn't that what it's supposed to do?

I'm not sure I see the problem with having alloc_page_frame() return a physical address. Isn't that what it's supposed to do?[/quote]

Octocontrabass wrote:

bayesian wrote:How can a good design to manage those unmapped memory over 1GiB?

Since you brought up Linux, here's a description of how Linux deals with it. In short, the unmapped areas are temporarily mapped when the kernel needs to access them.

bayesian wrote:And if my function such as alloc_page_frame() return a physical address, will the MMU automatically translate it to virtual address?

The MMU only translates virtual addresses to physical addresses. Usually you don't need to translate physical addresses to virtual addresses, but if you do, the MMU won't help you.

bayesian wrote:If not, how to fix it?

I'm not sure I see the problem with having alloc_page_frame() return a physical address. Isn't that what it's supposed to do?

Thank you for your reply. Currently I understands that in such design kernel will have 1GiB space address. And I have another question about the remaining physic memory space over 1GiB. Since kernel cannot cover those physic memory over 1GiB, I imagine that those pages will be aissgned for user program and if needed also can be assigned for kernel. And if a user program needs a new page, OS will firstly try to find a new page in physic memory over 896MiB or 1GiB. Is that correct?

Everything that @Octocontrabass said, plus

bayesian wrote:I can only use up to 1GiB memory even the physical memory is over 1GiB.

Why? If your page frame allocator returns 4G addresses, then any of that 4G can be mapped in the top 1G. But your page allocator should probably return page frames (that is, physical address >> 12), that way you could handle all 36 bits of PAE on 32 bits.

bayesian wrote:will the MMU automatically translate it to virtual address? If not, how to fix it?

How could it? You have to set up paging tables for that. Ideally, you should have a virtual memory allocator, which allocates linear addresses, and if and when it's out of free pages, it would call the page frame allocator. You should not call the page frame allocator (that returns physical addresses) directly, only through the virtual memory allocator (that returns linear addresses).

(BTW almost forgot, in protmode linear address only equals to virtual address if your segment descriptor has a base of 0 and size of 4G, which is strongly recommended.)

bayesian wrote:And if a user program needs a new page, OS will firstly try to find a new page in physic memory over 896MiB or 1GiB. Is that correct?

Not exactly. Think of this way:

Address space #1: 0 to 0xBFFFFFFF user space for process A (RAM a), 0xC0000000 to 0xFFFFFFFF kernel space (RAM b)
Address space #2: 0 to 0xBFFFFFFF user space for process B (RAM c), 0xC0000000 to 0xFFFFFFFF kernel space (RAM b)

So while the virtual memory looks identical for process A and process B, different RAM pages are mapped actually, but for kernel space the same RAM is mapped for both processes. What the physical address is, doesn't matter at all. For example, many OS uses 1M for RAM b, and uses any physical page it could find (< 1M or > 1M+kernel size) as RAM a and RAM c. Look at here, and imagine that on the picture "05x" is the mapping for 0xC0000000 to 0xFFFFFFFF.

Cheers,
bzt

bayesian wrote: Thank you for your reply. Currently I understands that in such design kernel will have 1GiB space address. And I have another question about the remaining physic memory space over 1GiB. Since kernel cannot cover those physic memory over 1GiB, I imagine that those pages will be aissgned for user program and if needed also can be assigned for kernel. And if a user program needs a new page, OS will firstly try to find a new page in physic memory over 896MiB or 1GiB. Is that correct?

The kernel has access to the page tables, so it can cover whatever memory it wants. If you reserve the top GiB of physical addresses as kernel space, the kernel can then map whatever physical addresses it chooses into that window. Linux (on 32-bit systems) keeps the bottom 896 MiB of physical memory mapped at all times, to be able to access it quickly and without having to remap anything. The rest of the top 1 GiB is used to temporarily map anything outside of the bottom 9896 MiB of physical memory that the kernel needs to access.

Linux will try to assign pages *under* the 896 MiB mark when memory is needed (either by user programs, or by the kernel), because those are the pages that it can access most quickly. Once everything under 896 MiB has been used, it will start using memory above that mark. In theory, for userspace allocations, the kernel could just write to the page tables and assign those pages to userspace without ever mapping them for itself, but in practice, it's often necessary for the kernel to do something with those pages before assigning them to userspace. For instance, if a file is being mmap()ed, the pages used for the mapping will need to be filled with data from the file before they are returned to userspace. For an anonymous mmap(), it's generally good practice to zero-fill the pages returned (and Linux actually does this). If the kernel needs to access the pages it is assigning before assigning them, and the bottom 896 MiB is all used, then Linux figures out which physical address it needs, finds a virtual address in the temporary mapping area to map it at, maps it, writes whatever data it needs (maybe even reads data), and then maps the page into userspace.

The pragmatic answer here is: go to 64 bit mode. 32 bit systems with huge amounts of memory are not worth supporting unless you have a good reason to do so. (There is discussion to remove this feature from Linux as well.)