关于嵌入式系统， 使用MMU还是不使用MMU？

之前在去某一家公司面试的时候， 被问到了实时系统RTOS， 也被问到了MMU， 这两个还好。

后来面试官问到RTOS中是否需要使用MMU， 使用会对系统产生什么样的影响， 还是被问到了。 由于本人之前工作中从事的嵌入式系统开发工作当中用的Vxworks， QNX的项目，都没有使用MMU的， 只对MMU有个基本的认识， 就是内存管理单元， 虚拟内存地址与物理内存的映射， 并且分页管理虚拟内存等等。

针对这个到底在嵌入式系统中该不该使用MMU， 今天读到了一篇很好的文章， 特记录地址并且总结如下：

网址：

To MMU or not to MMU?

http://www.embeddedinsights.com/channels/2010/07/21/to-mmu-or-not-to-mmu/ 

名词： 

MMU- Memory Management Unit

MPU- Memory Protection Unit

 

观点总结如下：

1. 很确定的讲那些包含MMU的处理器CPU 基本都是32位地址空间的。 其余的 8位，16位的处理器都不包含MMU。 而这些处理器占据了选型手册的几乎60页！

原文：

I think it is safe to say that processors that include MMUs are predominantly limited to the 32-bit processor space. While there are some 8-, and 16-bit processors that lay claim to an MMU, the majority of these sized processors, listed across approximately 60 pages in the directory, do not include an MMU.

2. Arm Cortex M3 不支持MMU 但是支持一个可选的MPU。 MMU 目前仅在 ARM Cortex-Ax系列的处理器被支持， 而 ARM Cortex-Rx 系列处理器仅支持一个可选的MPU。（注意此话是在2010年说的，目前新出的ARM芯片可能有变化）

The Cortex-M3 does not support an MMU, but it does support an optional MPU (memory protection unit).MMU support only exists in the Cortex-Ax class processors with the Cortex-Rx processors only supporting an optional MPU.

3.MMU回降低访问物理内存以及本地总线的速度。如果你使用us/OS这类仅有一个进程（统一地址空间）的多线程的操作系统， 使用MMU会是你访问本地总线的速度降低2-10倍， 具体降低多少取决于你如何做。

MMU slows down access to the physical memory and local bus, at least on the “large” processors like PowerPC or Intel. If you run uC/OS with multiple threads (not processes) there is no advantage of setting up MMU except that it slows down local bus access 2 to 10 times depends how you do it.  

4. 如果你的系统是设计成多进程的 复杂系统， 由多个team共同开发， 那你最好使用MMU。如果你是开发一个几万行代码的高性能系统， MMU将会影响你的系统性能。

The bottom line if your system is complex and built upon multiple processes written by multiple teams you better off with MMU. If you are building small (a few million lines of code) high performance system MMU will hinder your performance.

5. MMU单元提供了对逻辑地址层到物理地址层的保护和管理， 所以我建议即使是单进程的情况下仍然使用它。

An MMU provides both protection, and management in the form of a logical to physical mapping layer, both of which I’d suggest have their uses even without multiple processes.

6. MPU给你的应用程序提供了内存保护， 而MMU给你提供了全部的虚拟内存保护（包含MPU）。MMU单元将会由于频繁的访问页表而降低系统的速度， 但是MPU却非常时间效率高 - 通常只需要在线程发生改变的时候load一部分特殊的寄存器。如果你的系统对实时性要求高， 使用MPU时明智的， 而且使用RTOS来提供API来控制它， 从而使事情变得简单。...

The MPU gives your application memory protection, while an MMU gives you full virtual memory (with MPU implied). An MMU will slow down a system (due to frequent accesses to the page table), but an MPU is very time efficient– usually just loading some special registers when there is a thread change.

If you have a system that is mission critical, the use of an MPU is wise, and having an RTOS that provides API’s to control it makes life easier. This way, each thread can have some guaranteed sections of memory. If the RTOS also guarantees a certain amount of CPU time, then you have a much safer system.

7.MMU不仅存在performance的问题， 还很可能导致不确定性， 比如， 当基于地址页的转换被使用的时候。...。 当地址转换没有在cache中成功找到映射地址， 或者上下文任务切换导致了很多东西都需要reload， 每一个页表遍历都增加了额外的内存访问。

An MMU is not just a performance hit, it can be an especially non-deterministic one, for example, when page-based address translation is involved. That common type of translation minimizes its performance penalty by caching translations between virtual and physical addresses. However, when the translation misses in its cache, or context switching causes many things to be reloaded, each “page table walk” adds various additional memory accesses.

8. 我怀疑对于高端控制器， 使用MMU会导致performance的问题 （译者注：此种情况下由于处理器高端， 虽然MMU降低了性能，但是任然可以满足系统的性能要求）。但是其增加的复杂性（额外的地址转换步骤等）， 所以避免使用它， 如果他没有什么必要的话。

I doubt performance when using a MMU is an issue for high-end controllers, but the added complexity is (extra address translation step), so better avoid if it offers nothing.

9. 我冒险的说， 除非你所运行的系统受到很严重的物理限制而性能问题突出， 否则我们大部分人都会使用MMU， 因为从performance的角度看它根本就不是问题。

I’d venture to say that unless you’re running up against hard physical limits, plenty of us can make having an MMU a non-issue from a performance perspective.