Connect with us

memory management unit

Discussion in 'Electronic Design' started by [email protected], Feb 24, 2006.

Scroll to continue with content
  1. Guest

    Hi
    has anybody worked on memory management unit?
    i have few basic doubts about MMU page table.
    What should b the size of page table if my main memory is 4KB?

    u can also reply me on :

    cu

    Sachin
     
  2. PeteS

    PeteS Guest

    Which MMU?
    Embedded into a SoC or standalone?

    Different MMUs have different characteristics.

    Cheers

    PeteS
     
  3. Guest

    Hi pete
    it is embedded in SoC
     
  4. PeteS

    PeteS Guest

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

    Cheers

    PeteS
     
  5. Guest

    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?
     
  6. 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-
     
  7. Ken Smith

    Ken Smith Guest

    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.
     
  8. Joseph2k

    Joseph2k Guest

    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.
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-