rwarner wrote: > >>For headless systems and ones semi-stagnant in memory > >>allocation/reallocation an MMU-less system has many advantages. > > >However, what they also do is run an "ssh" command every 30 seconds to > >report home. That's enough to start the fragmentation problems. > This is in effect a new and delete every 30sec. It may not be Java or > C++ code that requires the garbage collection. But, causing the system > to act in object new/delete fashion has the same effect.
Ah, see, I regard every 30 sec as "slow" and "semi-stagnant". :-) I regard 10 million new/deletes per second as "non-stagnant" :-) If it was every 10 hours, would that be better? It would still fail in the same way, degrading to the point of being unable to login, but more slowly. > Any way to keep the ssh session open constantly? Actually, we do. The 30 seconds is just _checking_ that the ssh session is still verifiably alive. There's an awful lot of different things to refactor in that way, including code written by our customers, and by inexperienced people who can't be expected to understand these nuances. Uglifying scripts and/or replacing them with C programs has a substantial engineering cost too. What is most likely is that I may turn around your suggestion about VMs, and implement a fragmentation-resistant VM on this thing, so they can run their scripts without causing trouble :-) > >There real trigger is the kernel's file handling. My system streams > >files from a local disk. The kernel is quite unstable in it's file > >cache management on no-MMU systems. Either it creates the worst case > >for fragmentation (page_alloc.c) or it allocates so slowly and > >interacts poorly with cache reclamation that it severely reduces > >performance (page_alloc2.c), losing about 40% CPU just to the kernel's > >memory management. > 'local disk' implies to me that it is a large scale system. Not really. It's just a tiny box containing one SOC, glue, connectors and a small hard disk, and 64MB RAM (32 used for coprocessing, 32 for Linux). > disk caching is in effect a file system new/delete mechanism as > well. Sort of. It is lots of new/delete, but the fragmentation pattern is highly dependent on the caching heuristics. The appropriate cache heuristics don't add to fragmentation problems even if it's doing millions of new/delete per second - you can prove this (just keep the cache a small percentage of RAM, for the simplest example). This is also an example of where Linux doesn't perform well with no MMU, and is especially bad at causing fragmentation (or running very slowly with a workaround). There's nothing _intrinsic_ about fast, effective disk caching which causes fragmentation. > ? is it a local ram disk? If yes, do you force a sync on > the filesystem periodically? No, ordinary ext3 fs. We're reading from the disk. Just reading causes a major problem. when we write, it's worse, but we don't do that much. > Also is the memory in the file system getting fragmented? If yes, is it > possible to mount/unmount (possibly pseudo reformat as well) to fragment. No, because we're continuously streaming from the disk (in some modes it's a 24/7 video player). If I have the time and motivation, I will eventually use O_DIRECT and/or fadvise and/or 2.6 kernel I/O priorities and/or application-managed caching (like a database does) and/or fix the no-MMU allocator to be fast and well behaved, and I think it will fix these problems completely on our system, providing very reliable streaming. > >Unfortunately, my hardware doesn't have an MMU. Otherwise I would > >definitely use it - the slower context switches would be hugely > >outweighed by the speedup in kernel memory allocation, and being able > >to use all the RAM, and disk caching that works, would be a bonus. > > > >(I didn't know this when I started the project. I thought having no > >MMU wouldn't be much of a problem. I guess it is still largely a > >software problem, but a tough one that's a lot of work to solve.) > > > Can you replace the processor with an MMU variant? Sound's like you > need on based on the system usage Too much invested in the hardware design. We could produce a new design, but we still have to keep improving the firmware running on the existing units; there's quite a lot of them. There is an MMU variant, but it's not a trivial replacement (different CPU architecture), and one feature of our device that customers really like is the low price of the current one. If I were starting again, I'd opt for the chip with MMU this time, but right now, there's plenty to gain by improving the software. -- 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
