0

Why do we need the memory management unit?

It seems the only task of the memory management unit is to convert virtual addresses to physical address. Can't this be done in software? Why do we need another hardware device to this?

Claudio
  • 10,614
  • 4
  • 31
  • 71

2 Answers2

1

MMU (Memory Management Unit) is a hardware component available on most hardware platforms translating virtual addresses to physical addresses. This translation brings the following benefits:

  • Swap: your system can handle more memory than the one physically available. For example, on a 32-bit architecture, the system "sees" 4 GB of memory, regardless of the amount of the physical memory available. If you use more memory than actually available, memory pages are swapped out onto the swap disk.
  • Memory protection: the MMU enforces memory protection by preventing a user-mode task to access the portion of memory owned by other tasks.
  • Relocation: each task can use addresses at a certain offset (e.g., for variables), regardless of the real addresses assigned at run-time.

It is possible to partially implement a software translation mechanism. For example, for the relocation you can have a look at the implementation of gcc's fpic. However, a software mechanism can't provide memory protection (which, in turn, affects system security and reliability).

Claudio
  • 10,614
  • 4
  • 31
  • 71
  • `-fpic` has *nothing* to do with virtual memory. It would work exactly the same in an environment with no virtual addresses. (But it would be useful more of the time. Virtual addressing lets executable code be loaded at the same virtual address every time, regardless of what else is also running.) – Peter Cordes Nov 18 '15 at 12:48
  • `-fpic` can be used in Linux systems without the MMU to have some kind of relocation. – Claudio Nov 18 '15 at 13:40
  • 1
    It gets used on normal systems to make shared objects (libraries), since they can be loaded at any address. For non-library executables, it's an alternate solution to relocation problem that virtual memory solves. That doesn't mean it's a partial implementation of VM, though, just a different solution to a problem that you have when you don't have VM. It still doesn't allow the code to move to a different physical address (e.g. after being evicted and later paged back in), because there are probably some addresses in register pointing to the old pages. – Peter Cordes Nov 18 '15 at 13:54
  • IDK, I just think it's the wrong thing to emphasize. It's a subtle minor point, when there are several huge major points (e.g. memory protection gives you security (kernel vs. user, and multiple users, stability (one buggy program can't crash the system)) – Peter Cordes Nov 18 '15 at 13:56
  • I don't really understand this answer. It seems to just provide the benefits of virtual memory. But, the question was why the MMU is necessary for virtual memory management, not why virtual memory is beneficial. If you look at the description of virtual memory provided in Patterson & Hennessy Computer Organization and Design, they go through the entire discussion without once mentioning MMUs. It's described as the OS maintaining the page tables in memory. The only reference I could find to MMUs in the whole book was in an appendix relating to GPUs. – MattHusz Feb 25 '22 at 17:38
0

The reason for a MMU component of a CPU is to make the logical to physical address translation transparent to the executing process. Doing it in software would require stopping to process every memory access by a process. Plus, you'd have the chicken and egg problem that, if memory translation is done by software, who does that software's memory translation.

user3344003
  • 20,574
  • 3
  • 26
  • 62
  • Does the OS decide the virtual to physical address mapping and then rely on the MMU to perform subsequent translation, or how does that work? Since each process needs its own page table, how does the the MMU know which process is currently running? Does the OS signal to the MMU during a context switch? Whose job is it to ensure the physical addresses of one process don't collide with those of another? – MattHusz Feb 25 '22 at 17:52
  • The OS creates the logical address space for the process. The OS has to maintain page tables that map the logical processes pages to physical pages. The mapping can change over time. Processes can share page tables or parts of page table in some systems to maintain common page mappings. The system address translations are the same for all processes so they can be shared. Usually, there is a set of privileged hardware registers that define the current page table(s). These registers get changed by the OS during a context switch. The OS has to ensure that processes aren't stepping on each other. – user3344003 Feb 26 '22 at 20:12