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?
Yes.
if yes , then what should b the size of page table.
and what these 1st and second level descriptors do?
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:
(
http://www.intel.com/design/pentium4/manuals/index_new.htm).
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-
