memory management unit

Which MMU? Embedded into a SoC or standalone?

Different MMUs have different characteristics.

Cheers

PeteS

Which one? It's impossible to help without knowing the specifics of the device. Full part number and manufacturer required.

Cheers

PeteS

Hi Pete In my case i am designing MMU based on ARM processorMMU guidelines. its specification says it can supprt mapping sizes of 4KB,64KB,1MB and

16MB. is this mapping size related to page table? if yes , then what should b the size of page table. and what these 1st and second level descriptors do?

Yes.

It is difficult to provide a concise description of how virtual memory works in only a few paragraphs, but that's what you need to know. I've never used an ARM core so the following description is based Intel IA-32 family. You can read the chapter on Logical And Linear Addressing in the System Programming Guide on this page for Intel CPU:

While you're reading this chapter, there are a few things you should keep in mind"

Physical memory is physical memory. The hard part has to do with how the memory was intended to be used by running programs. Once you considered the restrictions that were anticiapted by the MMU designer, you can see why most modern MMU's utilized double-indirection to implement virtual memory.

Programs running on an operating system will request chunks of memory in unpredictable sizes. Traditionally, with no virtual memory, the OS would accommodate requests by hunting the available physical memory for an unallocated region large enough to satisfy the request. The problem is that if the request sequence is [big chunk] [small chunck] [big chunk], and the program that asked for [small chunk] releases [small chunk], you end up with a hole between the two [big chunk]'s. The next time a program asks for a [big chunk], the space between the two [big chunks] cannot be used, even though it is free. Over time there will become many such holes, and their net size could be many times larger than one [big chunk], but none of them can be used. This is called fragmentation.

Modern MMU's reduce this problem by finding a way to compact the holes. To do this, the address range allocated to a program must be decoupled from the actual physical memory allocated. This is the indirection. Indirection allows a program to see a large linear address range for allocated memory, but as the memory is accessed, the underlying cells can be discontiguous. The MMM directs access to the appropriate physical pages. The page tables provieds mapping from the address to physical page.Surely you can see that, with indirection, the MMU can take address 0xFFFE0000 and make it access the byte at 0x0000EFFF on the external bus.

That's one level indirection.

The reason you have two levels has mostly to do with keeping programs from interfering with each other's memory while silmutaneously using the same mechanism to allow them to interfere if that is what is desired. Without going into too much detail, if you think long and hard about all the different scenarios for sharing or not sharing of memory (totally disjoint, totally shared, part shared/part disjoint, etc), you will arrive to conclusion that the universal model has to be double-indirection.

The reason for multiple page sizes has to do with efficiency of overhead. Any chunk allocated by the OS has to be allocated in full pages because of the paging mechanism itself. The C/C++memory management code in the program then chops up this page as necessary, but you can be sure, if an initial request goes to the kernel, a whole page is granted to the user-mode program. There is overhead in physical memory to keep track of which pages have been granted by OS (the overhead is the descriptors + OS tracking overhead). If pages are too small (less than 4KB), you end up wasting too much physical memory on descriptors and tracking. If pages are too large (> 16MB), you might end up given a program a 16MB page when all it wanted as 45 bytes. Since it is hard to tell in advance what kind of programs will be running on a CPU, the MMU provides bits to allow the OS designer to choose the page size. In Windows, it's 4KB, since that happens to be a nice size for the kinds of programs that we write.

-Le Chaud Lapin-

Are you doing VM? I'll answer for both cases:

No VM: This 4KB of memory, you shouldn't have a MMU at all. Use those extra transistors to make another K of memory.

With VM:

Where does your swap space live? I assume it is a hard disk. Sell the hard disk and go buy some RAM.

--
--
kensmith@rahul.net   forging knowledge

If your main memory is 4 kB you do not want an MMU at all. If for some reason your customer is requiring one, you want the smallest block size available > 64 B. if the smallest block size is 4 kB you cannot even use one.

--
JosephKK
Gegen dummheit kampfen die Gotter Selbst, vergebens.  
--Schiller