Andrew Burgess wrote:
On 05/23/2011 08:12:13 AM, Gordan Bobic wrote:
> 2) My testing shows that the coreutils software implementation is
> actually quicker on checksumming large files. Not a lot, mind you, but
> the difference is measurable (1.924s for sha1sum and 1.998s for
> sha1 for a kernel tar.bz2 ball, for the best of three runs of each).
> the sys+user time for sha1sum adds up to the wallclock total, whereas
> for the cryptodev accelerated openssl run, the sys+user is 0.620s,
> less than a third of wallclock.
cryptodev probably used the CESA hardware.
It is - the mv_cesa kernel process starts to show up in top when the
crypto engine is being used.
since it isnt using cpu time
i guess its technically not a bug.
I never said it was a bug, I was merely meaning to say that it is great
that the CPU is freed up to do other stuff. :)
i wonder how much you could actually use the cpu for other things?
would a little cpu bound program running at idle prio get work done
during your benchmark? that might be a big argument for cryptodev...
or even run both openssl and coreutils in parallel; total bytes
per second (and heat and power) should increase.
As far as I can tell - yes. If I'm churning without cryptoddev, the CPU
sits at 0% idle. With cryptodev and large blocks the idle CPU time is
typically > 70%. So the remaining 70% of CPU could indeed be used for
something else, such as additional crypto if needs be (see the comments
in the article linked earlier in this thread that point out this very