On 06/13/2011 05:39 PM, Kent Borg wrote:
> I was assuming that drivers, responding to an interrupt from some
> external event, would want to make this call.
> Such as a network driver.
Those already are doing this.
> Two points:
>
> 1. Why look at the high-order bits? How are they going to have
H. Peter Anvin wrote:
> However, the big issue with this is that it's recursive... what
causes this to
> be invoked... probably an interrupt, which is going to have been
> invoked by a timer, quite possible the TSC deadline timer. Oops.
I was assuming that drivers, responding to an interrupt fr
Venkatesh Pallipadi wrote:
On Mon, Jun 13, 2011 at 3:06 PM, Jarod Wilson wrote:
TSC is high enough resolution that we can use its low-order byte to
stir new data into the random number generator entropy pool.
From what I vaguely remember from years past, rdtsc, especially last
few bits of
On Mon, 2011-06-13 at 18:06 -0400, Jarod Wilson wrote:
> Many server systems are seriously lacking in sources of entropy,
> as we typically only feed the entropy pool by way of input layer
> events, a few NIC driver interrupts and disk activity. A non-busy
> server can easily become entropy-starved
On 06/13/2011 03:27 PM, Venkatesh Pallipadi wrote:
> On Mon, Jun 13, 2011 at 3:06 PM, Jarod Wilson wrote:
>> TSC is high enough resolution that we can use its low-order byte to
>> stir new data into the random number generator entropy pool.
>
> From what I vaguely remember from years past, rdtsc,
Venkatesh Pallipadi wrote:
On Mon, Jun 13, 2011 at 3:06 PM, Jarod Wilson wrote:
TSC is high enough resolution that we can use its low-order byte to
stir new data into the random number generator entropy pool.
From what I vaguely remember from years past, rdtsc, especially last
few bits of it
On Mon, Jun 13, 2011 at 3:06 PM, Jarod Wilson wrote:
> TSC is high enough resolution that we can use its low-order byte to
> stir new data into the random number generator entropy pool.
>From what I vaguely remember from years past, rdtsc, especially last
few bits of it are not very good as rando
Add a new function pointer to struct clocksource that can optionally be
filled in by clocksources deemed to be high enough resolution to feed
the random number generator entropy pool.
CC: Matt Mackall
CC: "Venkatesh Pallipadi (Venki)"
CC: Thomas Gleixner
CC: Ingo Molnar
CC: John Stultz
CC: He
TSC is high enough resolution that we can use its low-order byte to
stir new data into the random number generator entropy pool.
CC: Matt Mackall
CC: "Venkatesh Pallipadi (Venki)"
CC: Thomas Gleixner
CC: Ingo Molnar
CC: John Stultz
CC: Herbert Xu
CC: "David S. Miller"
Signed-off-by: Jarod W
This is a new interface for adding entropy data to the random number
generator. The low-order byte of a delta between successive clocksource
reads is mixed into the pool, with one bit per bytes of data mixed in
credited to the entropy pool.
CC: Matt Mackall
CC: "Venkatesh Pallipadi (Venki)"
CC:
HPET is high enough resolution that we can use its low-order byte to
stir new data into the random number generator entropy pool.
CC: Matt Mackall
CC: "Venkatesh Pallipadi (Venki)"
CC: Thomas Gleixner
CC: Ingo Molnar
CC: John Stultz
CC: Herbert Xu
CC: "David S. Miller"
Signed-off-by: Jarod
This is a fairly simple driver that just starts up a kernel thread that
periodically calls the active clocksource's entropy-gathering function,
if it has one. The default interval of 100us between polls doesn't show
any measurable impact to cpu usage on a core 2 duo test rig here, and
ensures the e
Many server systems are seriously lacking in sources of entropy,
as we typically only feed the entropy pool by way of input layer
events, a few NIC driver interrupts and disk activity. A non-busy
server can easily become entropy-starved. We can mitigate this
somewhat by periodically mixing in entro
13 matches
Mail list logo
