Re: random: Benchamrking fast_mix2

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Jun 12, 2014 at 08:23:04PM -0400, George Spelvin wrote:
> Another cache we might be hitting is the branch predictor.  Could you try
> unrolling fast_mix2 and fast_mix4 and see what difference that makes?
> (I'd send you a patch but you could probably do it by hand faster than
> appying one.)

Unrolling doesn't make much difference; which isn't surprising given
that almost all of the differences go away when I commented out the
udelay().  Basically, at this point what we're primarily measuring is
how good various CPU's caches work, especially across context switches
where other code gets to run in between.

If that's the case, all else being equal, removing the extra memory
reference for twist_table[] does make sense, and something else I've
considered doing is to remove the input[] array entirely, and have
add_interrupt_randomness[] xor values directly into the pool, and then
let thast fast_mix function stir the pool.

It's harder to benchmark this, but at this point, I think we know
enough to be confident that this will be a win on at least some
platforms, and so long as it's not a massvie lose from what we had
before, I'll be fine with it.

I also think that it's going to be worthwhile to do the RDTSC
measurement in vitro, and calculate average and max latencies, since
it's clear that there are real limitations to userspace benchmarking.

Cheers,

						- Ted