Hi, For MicroBlaze, the penalty for using the MMU is much less. For the clock frequency, on average we see a 15% penalty due to the MMU. However, usually the CPU is not run at the maximum clock frequency, but rather at the available clock or memory speeds due to system issues.
When we run an application on Linux with or without the MMU, we see a penalty of approximately 4% of the computational performance when using the MMU. This is an average for all applications we have measured; the penalty will of course vary between applications. For a Linux system, using the MMU will actually increase the overall performance due to e.g. demand paging and copy-on-write. With the MicroBlaze MMU hardware implementation, there is no need to flush the cache when switching process. Göran -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael Schnell Sent: Friday, March 27, 2009 9:48 AM To: uClinux development list Subject: Re: [uClinux-dev] MMU trade-off > Someone threw a number into the discussion and said enabling the MMU would > cause performance losses of about 30-40 percent, thus if we switch to Linux > at all it would have to be ucLinux. > uCLinux does not mean "without MMU". uCLinux does support several architectures with MMU. The numbers are certainly not relevant, as the degradation due to MMU-usage depends on multiple influences. Hardware: Maybe the CPU in fact is faster if the MMU is disabled. I am using a NIOS CPU that can be configured with and without MMU (here in fact the MMU hardware is not implemented in the FPGA design). While two years ago (as Altera was up to create the MMU design) I was told the MMU would reduce the maximum usable clock frequency by 50 % not that the design is mature, the degradation seems to be 20 % at most. Maybe there are delays due to additional hazards when the CPU needs to wait for memory access. I have no numbers on that yet. I don't suppose the clock specification varies regarding enabling the MMU with "Hardware"-CPUs, but there might be additional hazards when enabling it Software: Of course programming the MMU registers need to be updated with any process switch. So this is only relevant if you do many process switches and this depends heavily on the application you do. MMU-design: It's known that the MMU-design with ARM based chips is bad in that the cache is between the CPU and the MMU instead of between the MMU and the RAM (as e.g. with the x86 CPUs). This is why you need to flush the cache whenever the MMU registers are updated. This makes the task switch very slow. -Michael _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
