Andrew Kohlsmith (lists) wrote: > On April 17, 2008 12:43:37 pm Jamie Lokier wrote: > > > Video streaming i would consider a large scale system. Why was a non > > > MMU processor selected for a video streaming application? > > > > Price and availability of a chip that did good video (HDTV even), and > > we didn't know the no-MMU penalty at the time. > > What on earth is the no-MMU penalty for video applications?? Memory > fragmentation? Or is there more to it?
The main penalty is Linux doesn't do fast file streaming very well with no MMU. This isn't really fragmentation, it's Linux memory subsystem issues. In our application, the streaming performance bottleneck is usually Linux kernel itself, not the video decoder. It's default page allocator and reclaimer causes a lot of fragmentation (it wasn't designed to avoid it, there's no need with an MMU), and in some ways is particularly bad. (Some of the "Enterprise" changes to 2.6 kernels to reduce fragmentation in multi-gig system may have improved the no MMU behaviour too, which is nice, but I didn't notice any of the implementors/testers caring about embedded). The alternative (page_alloc2.c) is better but slow enough to be a significant bottleneck, and it also it can get into states like 40% CPU in kswapd for several minutes, while streaming goes stuttery - and that's _after_ tuning it. The OOM killer doesn't really sort it out so you can still login, as well as an MMU. Without an MMU, emergency freeing 2MiB doesn't necessarily mean you can allocate a large block to start even a simple program like /bin/sh. With an MMU, it practically guaranteed to work. Another penalty is that shared libs aren't supported on most no-MMU architectures. That means memory wasted on duplicate code. As you can imagine, video codecs are rather large, and an MMU system is typically geared around loading the appropriate codec shared libs as needed. With no MMU, you have to choose between making a huge executable, or invoking different executables depending on which codec the next file needs, with binary code duplication, or something home grown. Whichever way, it's totally different to what all the desktop video people are doing. Another problem from lacking shared libs is more difficult LGPL compliance. With the main C library (uClibc) being LGPL, this is important. Another is some handy programs (with no alternative) like iptables don't work, because they depend heavily on loading shared libraries at runtime. (Or does that work?) As far as I could see, there's no fully static linkage option for iptables. If there is a way, the downside is that it's not obvious or not easy. Another is that because fork() requires an MMU, quite a few useful programs in general use cannot be run on the device, or need patching, sometimes quite difficult patching. Getting rsync to work without fork() was interesting, and still has faults (we just avoid those options), but was very worthwhile too. We use it to copy video files. Needing to fix the stack size, of each thread, in advance is another thing. Not usually a problem, but for certain programs (rsync), they need small stack most of the time, but a huge stack sometimes, otherwise cue random corruption. Apart from those things, it's pretty good :-) Basically, with an MMU, a lot of things you're used to on modern Linux work just fine and just like the authors/you expect, provided you have the memory. You can use a lot of stuff off the shelf, or slimming it down. Without an MMU, quite a few programs cannot be compiled out of the box, or don't behave well, or require substantial patching to behave well, and I include parts of the kernel's mm/ and fs/ in this. Most of the problems are solvable in software, but it creates a lot of work, and keeps you away from the showing off fun stuff. -- Jamie _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
