[lkml]   [2013]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH,RFC] random: make fast_mix() honor its name
On Sun, 22 September 2013 17:27:52 -0400, Theodore Ts'o wrote:
> The structure of the mixing functions in /dev/random has been well
> studied, and validatetd in a number of different academic papers. So
> I prefer to stick with the basic architecture, even as it is scaled
> down for speed reasons and beause the pool is smaller.

And I want to keep that function. Essentially the point of fast_mix()
is to ratelimit _mix_pool_bytes(). Naïve ratelimiting would simply
discard the input once the ratelimit has been reached. My proposal is
to still use the input bits, but use a really cheap mixing function.

Your version of fast_mix() failed in the "really cheap" department.
As a result, it showed up in profiles and at least one idiot (me)
reverted to naïve ratelimiting. It could have been worse, I was
explicitly asked twice to just remove the call to

So don't think of my patch as weakening the mixing, but as
strengthening the ratelimited mixing. If we have few interrupts,
_mix_pool_bytes() will be run once a second, if we have many it will
be run once every 64 interrupts. And in the latter case, the input
for _mix_pool_bytes() is much better than with naïve ratelimiting.

And you should do the same for add_timer_randomness(), where again you
have ratelimiting. Once trickle_thresh is reached your code simply
discards most randomness. Only once in 4096 call do you use all the
bits you get - most of which will be predictable. Why not use a cheap
mixing function for the other 4095 calls and ensure we have many good
bits on call 4096?


You can't tell where a program is going to spend its time. Bottlenecks
occur in surprising places, so don't try to second guess and put in a
speed hack until you've proven that's where the bottleneck is.
-- Rob Pike
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2013-09-23 00:41    [W:0.124 / U:1.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site