>Even backgrounded? That took 11.5 seconds, still slower than -j2 on md5sum.
>The point is to keep one processor busy doing jffs2 decompression >work while the other processor is doing md5 stuff. (You mentioned >it was an SMP system.) Like the making of sausage, or politics, I really _don't_ want to have to know too much about what is going on. The beauty of using -j2 is that I don't care which subtask takes how much time, md5 or jffs2, _both_ cpu's are kept busy all the time, except for part of the last file to be processed. If the relative efficiencies of the two pieces of code change, it still keeps fully busy. Automatically. I would expect this in this situation, because there are no variable I/O delays to tune to. Flash is just RAM, and there are no seek or read delays. It's purely CPU-bound, so I would not expect a pre-caching scheme to yield any benefit. With rotating media, one _might_ see some benefit to a pre-caching cat. Or not, that stuff can get pretty tricky. >But yeah, sounds like the dominant factor here is cache population in the >kernel, and most of the CPU is consumed by the jffs2 driver. It would make >just as much sense to add a -j option to cat as it would to add it to >md5sum here. Except that md5sum -csj2 has a deterministic result, a pass/fail status, whereas the order of things in a cat tends to matter. What I did works, it's simple, and it's done at the right place in our system so that we can decide to continue booting or failover to the other flash bank. -- Jim _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
