[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
cprng_fast and interrupts [was Re: Patch: cprng_fast performance - please review.]
Date: Fri, 18 Apr 2014 21:50:46 -0400
From: Thor Lancelot Simon <tls%panix.com@localhost>
> Are there actually any callers of cprng_fast at IPL_HIGH? Are there
> actually any legitimate random decisions to be made at IPL_HIGH? I'm
What do you get if you cross an elephant and a rhinocerous? Given that
what we do within the spl* takes very little time I am inclined to say
what spl we go to hardly matters, and be very conservative. The real
question here, I think, is whether we should spl*() at all, or forbid
use of cprng_fast() from interrupt context entirely.
In partial answer to my question, there are calls to libc/libkern
random at IPL_HIGH in various statistical clock interrupt handlers, so
if we want to replace that by cprng_fast we shall need it to work at
IPL_HIGH (which currently it doesn't really!).
There are also many calls to cprng_fast throughout the network stack,
certainly in softint handlers if not also in hard interrupt handlers,
so we need cprng_fast to work at IPL_SOFTNET if not IPL_VM.
Certainly we should not do more than a small constant amount of
computation with interrupts blocked. For IPL_VM, hundreds or even a
couple thousands of cycles of crypto are probably acceptable -- we
already do, e.g., red/black tree operations at IPL_VM.
But what is the maximum acceptable latency at IPL_HIGH? Is, say, 400
cycles too long to block interrupts? Is that too slow for statclock
interrupts? (Should we have guidelines for these written down?)
Much as I want to discourage the use of non-cryptographic PRNGs for
any purpose, I am willing to entertain the notion that the statclock
interrupt handler may be adequately serviced by an LCG or LFSR too.
Main Index |
Thread Index |