On Friday 27 March 2009 12:15:57 Lennart Sorensen wrote: > On Fri, Mar 27, 2009 at 08:39:57AM +0100, Thomas H?berle wrote: > > A client is currently considering to switch Linux as operating system on > > his devices. In a recent discussion the theme "virtual memory & MMU > > usage" came up. All used CPUs have a MMU, but it is not used due to > > performance reasons as the developers state. 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. > > Wow that's a claim I wouldn't believe without some serious detail > explaining why on that particular cpu for that particular software setup > it had that kind of impact. > > > Unfortunatley I don't have enough experience in low-level programming, so > > I don't know if this is true, but I would like to know! As far as I > > understand the scope of your project are systems that simply don't have a > > MMU due to hardware design reasons. Is this correct? > > Of course I COULD run it on systems with a disabled MMU, but why should I > > if my processor has the luxury of a MMU and I already payed for it? Is > > the trade-off for hardware supported virtual memory (=enabling the MMU) > > really that significant as mentioned above? What are your experiences? > > Virtual memory is just one of the nice features of an MMU.
there are processors which implement other features that people consider part of the MMU (like protection). virtual memory is the most significant feature. > You also get shared libraries (well you can fake it on some uclinux > types even without an MMU but with very serious limitations). lies. there are no serious limitations at all with FDPIC ELF. it is functionality equivalent to ELFs running under a MMU. > You also get fork(). That's a big deal to a lot of code. Fork requires > being able to copy an address space (preferably efficiently), which an > MMU can help you do. It might be possible to do without an MMU, but I > am not sure, since I have never seen anyone do so. you cannot do fork() without virtual memory since both processes will have pointers to the same addresses and there's no way to relocate them. > You get the ability to memory map files. Handy for some tasks. you can memory map files without a MMU > You get the ability to do memory protection, so one process can't > accidentally write to another processes memory. Very good for containing > programming errors to a single process, and helps for debuging since a > stray pointer will be much more likely to go outside the virtual memory > space of the process than go outside physical memory. memory protection is not strictly part of the MMU. some processors implement MPU's (like the Blackfin processor) and the kernel supports it just fine. that gets you standard data/instruction rwx control. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ 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
