md5sum

Cathey, Jim jcathey at ciena.com
Mon Jun 22 17:30:28 UTC 2009


>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






More information about the busybox mailing list