Re: [PATCH-v2 4/4] random: clean up interrupt entropy accounting for archs w/o cycle counters

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

On Sat, Jun 14, 2014 at 03:28:49AM -0400, George Spelvin wrote:
> +	if (cycles || (fast_pool->notimer_count >= 32))
> +		credit++;
> 
> Ah, this addresses my concern about too few interrupts, too.  If the
> (non-timer) interrupt rate is less than 32/second, you'll never get any
> credit.

I'll want to measure the interrupt rate on things like a mobile
handset to see if this is a real problem or not, but the real question
is if you don't have a cycle counter, and the system is largely idle,
*and* all of the clocks are driven off of the same master oscillator,
how much entropy do you really get from measuring timing interrupts
where your time measurement has a granularity of 1/HZ seconds?  

Basically, at that point, you're getting most of your entorpy from
instruction_pointer(regs), and whatever the value of irq is --- and if
irq is mostly TIMER_IRQ, there's not much entropy there either.

Also note that the question is not whether the non-timer interrupt
rate is less than 32 seconds, but rather out of the last 64
interrupts, how many of the interrupts come from non-timer sources?
That's not the same thing, especially if you are running in tickless
mode, which most modern kernels for mobile handsets would want to do
for the obvious power savings reason.  Indeed the main concern on most
mobile handsets is that there aren't that many interrupts to begin
with, because they've been optimized out as much as possible.

The real answer is that ARM manufacuters have to get off their !@#!@?
duff and give us either a real clock cycle counter, or a real hardware
randum number generator, or both...

						- Ted